SqueakByExample:7.2: Difference between revisions

From 흡혈양파의 번역工房
Jump to navigation Jump to search
(SBE 테스트수행이중요한이유 페이지 추가)
 
(번역수정)
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
==테스트 수행이 중요한 이유==
==테스트 수행이 중요한 이유==


불행하게도, 많은 개발자들은 테스트는 그들의 시간을 낭비하는 것이라고 믿습니다. 무엇보다도, 그들은 버그를 만들지 않으며, 오직 다른 프로그래머들이 버그를 만든다고 믿고 있습니다. 우리들 대부분은 종종 “내가 좀더 많은 시간이 있으면 테스트들을 작성할 꺼야”라고 말해왔습니다. 만약 여러분이 결코 버그를 만들지 않고, 자신의 코드가 미래에도 결코 변경되지 않을 것이라면, 실제로 테스트들은 여러분의 시간 낭비입니다. 그럼에도 불구하고, 이것이 대부분의 경우에 있어 여러분의 어플리케이션이 하찮은 것이며, 여러분 또는 다른 누군가가 사용하지 않는다는 의미도 됩니다. 미래를 위한 투자로서 테스트를 생각해 보십시오: 테스트들의 스위트(suite)갖는 것은 지금 꽤 유용할 수 있지만, 미래에 여러분의 어플리케이션 또는 어플리케이션 환경에서 어플리케이션을 실행하고 변경할 때 엄청나게 유용하게 될 것입니다.  
불행하게도, 많은 개발자들이 테스트는 시간낭비라고 생각합니다. 무엇보다도, 이런 개발자들은 버그를 만들지 않으며, 오직 다른 프로그래머들이 버그를 만든다고 믿습니다. 우리들중 대부분은 "내가 좀 더 많은 시간이 있으면 테스트들을 작성할 꺼야"라고 자주 말하기도 합니다. 만약 당신이 결코 버그를 만들지 않고, 그렇게 작성된 코드가 앞으로도 결코 변경되지 않을 것이라고 한다면, 실제로 테스트는 시간낭비일 수 있십니다. 하지만 정말 그렇다면, 대부분의 경우에 있어 만들어진 어플리케이션은 하찮거나, 제작자 및 그 누구도 사용하지 않는다는 의미도 됩니다. 미래를 위한 투자로서 테스트를 생각해 보시기 바랍니다: 테스트들의 suite 를 가진다는건 현 시점에서도 유용하지만, 그보다 앞으로 만들게될 어플리케이션 또는 어플리케이션 환경에서, 어플리케이션을 실행하고 변경할 때 훨씬 더 유용하게 될겁니다.


테스트들은 여러가지 역할을 수행합니다. 첫번재로, 테스트들은 그것들이 담당하는 기능의 문서화를(documentation) 제공합니다. 무엇보다도, 그 문서화는 활성화 됩니다: 테스트 패스(the tests pass)를 지켜보는 작업은 문서화가 최신상태라는 것을 여러분에게 말해줍니다. 두 번째로 테스트들은 패키지에서 변경한 몇몇 변경사항들이 시스템에 있는 어떤 것도 망가뜨리지 않았다는 것을 개발자들이 확인하는 작업을 도우며 그러한 확신이 잘못 예상된 것으로 드러났을 때, 개발자들이 어긋난 부분을 찾는 작업을 돕게 됩니다. 마지막으로, 프로그래밍과 동시에 테스트를 작성하거나 또는 그 이전에 작성하는 것은 테스트를 실행하는 것에 관한 일 보다, 여러분이 디자인 하기 원하는 기능, 그리고 클라이언트에 보이는 방식에 대해 여러분이 더 많이 생각하도록 압력을 넣습니다. 코드를 프로그래밍 하기 이전에 테스트를 작성함으로써- 여러분은 실행할 여러분의 기능과 클라이언트 코드(the client code)와 상호작용하게 될 방식 그리고 기대되는 결과(the expected results)에 컨텍스트(the context)를 진술(state)하도록 강요받습니다. 여러분의 코드는 향상될 것입니다: 시도해 보십시오.
테스트들은 여러가지 역할을 수행합니다. 첫번째로, 테스트는 테스트가 담당하는 기능에 대한 문서를 제공하게 됩니다. 게다가, 이렇게 제공되는 문서는 활동적<ref name="역자주1">실행이 가능한 문서라는 점. 6.5에서 관련부분이 조금 설명되어있습니다</ref>입니다: 테스트가 제대로 통과된다면 테스트로 구현되는 문서화가 최신상태라는 의미가 됩니다. 두번째로 테스트들은 개발자가 패키지에 대한 변경사항으로 인해 시스템에 있는것들이 정상임을 확인하는것을 도와주며, 정상적일것이라는 예상에 대한 좋지않은 결과가 나오면, 개발자들이 문제가 있는 부분을 찾는것을 지원하게 됩니다. 마지막으로, 프로그래밍과 동시에 테스트를 작성하는-또는 그 이전에 테스트를 작성하는등-것은 테스트를 실행하는데 목적을 두는것이 아니라, 프로그래밍시 설계시 원하는 기능, 그리고 구현보다 고객에서 보여질지에 대해 더 많이 생각하게 합니다. 테스트를 먼저-코드를 만들기전에-작성함으로써 실행할 기능, 클라이언트 코드와 상호작용하는 방식 그리고 예상되는 결과에 컨텍스트를 기술하는것이 필요해집니다. 이렇게 해서 코드는 개선될 것입니다: 시도해 보십시오.
 
현실적으로 봤을때 어플리케이션의 모든측면을 테스트할 수는 없습니다. 하나의 어플리케이션 전체를 모두 테스트하는 것은 단순히 불가능한 작업이며, 테스트의 목적이 될 수 없습니다. 훌륭한 테스트 suite를 갖고 있어도, 어플리케이션에 버그는 생길 수 있으며, 이렇게 생긴 버그는 시스템을 손상시킬 기회를 엿보며 잠복하고 있을 수 있습니다. 만약 이러한 현상을 발견하시면, 그 버그를 활용하세요! 버그를 발견하자마자, 버그발생내용대로 테스트를 작성해서 버그를 드러나게 하고, 테스트를 실행해서 오류가 생기는 부분을 지켜보십시오. 이제 버그 수정을 시작하면 됩니다: 테스트를 진행하다보면 언제 테스트 작업을 끝내야 할지를 자연스럽게 알 수 있을겁니다.


우리는 모든 현실에 존재하는 어플리케이션의 모든 측면들을 테스트하지 않습니다. 하나의 어플리케이션 전체를 모두 테스트하는 것은 단순히 불가능한 작업이며, 테스트의 목적이 될 수 없습니다. 훌륭한 테스트 스위트(test suite)를 갖고 있어도, 몇몇 버그가 어플리케이션에 생길 수 있으며, 그 버그는 여러분의 시스템을 손상시킬 기회를 엿보며 잠복하고 있을 수 있습니다. 만약 여러분께서 이러한 현상을 발견하시면, 그 버그를 활용하십시오! 버그를 발견하자마자, 테스트를 작성하여 버그를 노출시키고, 테스트를 실행하여 오류가 생기는 장면을 지켜보십시오. 이제 여러분은 버그 수정을 시작할 수 있습니다: 그 테스트 자체가 여러분이 언제 테스트 작업을 끝내야 할지를 말씀드릴 것입니다.


==Notes==
==Notes==

Latest revision as of 05:35, 16 March 2013

테스트 수행이 중요한 이유

불행하게도, 많은 개발자들이 테스트는 시간낭비라고 생각합니다. 무엇보다도, 이런 개발자들은 버그를 만들지 않으며, 오직 다른 프로그래머들이 버그를 만든다고 믿습니다. 우리들중 대부분은 "내가 좀 더 많은 시간이 있으면 테스트들을 작성할 꺼야"라고 자주 말하기도 합니다. 만약 당신이 결코 버그를 만들지 않고, 그렇게 작성된 코드가 앞으로도 결코 변경되지 않을 것이라고 한다면, 실제로 테스트는 시간낭비일 수 있십니다. 하지만 정말 그렇다면, 대부분의 경우에 있어 만들어진 어플리케이션은 하찮거나, 제작자 및 그 누구도 사용하지 않는다는 의미도 됩니다. 미래를 위한 투자로서 테스트를 생각해 보시기 바랍니다: 테스트들의 suite 를 가진다는건 현 시점에서도 유용하지만, 그보다 앞으로 만들게될 어플리케이션 또는 어플리케이션 환경에서, 어플리케이션을 실행하고 변경할 때 훨씬 더 유용하게 될겁니다.

테스트들은 여러가지 역할을 수행합니다. 첫번째로, 테스트는 테스트가 담당하는 기능에 대한 문서를 제공하게 됩니다. 게다가, 이렇게 제공되는 문서는 활동적[1]입니다: 테스트가 제대로 통과된다면 테스트로 구현되는 문서화가 최신상태라는 의미가 됩니다. 두번째로 테스트들은 개발자가 패키지에 대한 변경사항으로 인해 시스템에 있는것들이 정상임을 확인하는것을 도와주며, 정상적일것이라는 예상에 대한 좋지않은 결과가 나오면, 개발자들이 문제가 있는 부분을 찾는것을 지원하게 됩니다. 마지막으로, 프로그래밍과 동시에 테스트를 작성하는-또는 그 이전에 테스트를 작성하는등-것은 테스트를 실행하는데 목적을 두는것이 아니라, 프로그래밍시 설계시 원하는 기능, 그리고 구현보다 고객에서 보여질지에 대해 더 많이 생각하게 합니다. 테스트를 먼저-코드를 만들기전에-작성함으로써 실행할 기능, 클라이언트 코드와 상호작용하는 방식 그리고 예상되는 결과에 컨텍스트를 기술하는것이 필요해집니다. 이렇게 해서 코드는 개선될 것입니다: 시도해 보십시오.

현실적으로 봤을때 어플리케이션의 모든측면을 테스트할 수는 없습니다. 하나의 어플리케이션 전체를 모두 테스트하는 것은 단순히 불가능한 작업이며, 테스트의 목적이 될 수 없습니다. 훌륭한 테스트 suite를 갖고 있어도, 어플리케이션에 버그는 생길 수 있으며, 이렇게 생긴 버그는 시스템을 손상시킬 기회를 엿보며 잠복하고 있을 수 있습니다. 만약 이러한 현상을 발견하시면, 그 버그를 활용하세요! 버그를 발견하자마자, 버그발생내용대로 테스트를 작성해서 버그를 드러나게 하고, 테스트를 실행해서 오류가 생기는 부분을 지켜보십시오. 이제 버그 수정을 시작하면 됩니다: 테스트를 진행하다보면 언제 테스트 작업을 끝내야 할지를 자연스럽게 알 수 있을겁니다.


Notes

  1. 실행이 가능한 문서라는 점. 6.5에서 관련부분이 조금 설명되어있습니다