SqueakByExample:7.9: Difference between revisions

From 흡혈양파의 번역工房
Jump to navigation Jump to search
(SBE 테스트에관한몇가지조언 페이지 추가)
 
(번역수정)
 
(6 intermediate revisions by the same user not shown)
Line 1: Line 1:
==테스트에 관한 몇 가지 조언==
==테스트에 관한 몇 가지 조언==


테스트의 메커니즘이 쉬운 반면에, 좋은 테스트를 작성하는 작업은 어렵습니다. 여기에 테스트를 디자인 하는 방법에 대한 몇 가지 조언이 있습니다.
테스트의 작동원리는 어렵지 않습니다만, 정작 좋은 테스트를 작성하는 작업은 어렵습니다. 이 아래에 테스트를 설계 하는 방법에 대한 몇 가지 조언이 있습니다.


'''Unit 테스트를 위한 Feathers의 규칙.''' Agile process 컨설던트이며 저자인 Michael Feathers는 다음과 같이 썼습니다.<ref name="주석7-3">See http://www.artima.com/weblogs/viewpost.jsp?thread=126923. 9 September 2005</ref>


만약 다음과 같을 경우 테스트는 Unit 테스트가 아니다:
'''Unit 테스트를 위한 Feathers 의 규칙.''' 애자일 과정 컨설턴트이며 저자인 Michael Feathers 는 다음과 같은 주장을 했습니다.<ref name="주석7-3">See http://www.artima.com/weblogs/viewpost.jsp?thread=126923. 9 September 2005</ref>


* 테스트가 데이터 베이스에 말할 경우
* 테스트가 네트워크 전체에 걸쳐 커뮤니케이션 할 경우
* 테스트가 파일 시스템을 만질 경우
* 여러분의 다른 Unit 테스트들의 다른 어떤 것과 동시에 실행되지 못할 경우
* 또는 테스트를 실행하기 위해 (config 파일과 같은) 여러분의 환경에 특별한 작업들을 수행해야만 할 경우<br>이러한 일들을 하는 테스트들이 나쁜 것은 아닙니다. 종종 이 테스트들은 작성할 가치가 있으며, Unit 테스트 장비로서 작성될 수 있습니다.  그럼에도 불구하고, 진짜 unit 테스트와 구별시켜, 변경사항들을 만들 때마다 빨리 실행할 수 있는 테스트들의 세트를 유지 하는 작업 또한 중요합니다.


너무나 시간이 많이 걸리므로, Unit 테스트 스위트 실행을 원하지 않는 상황에
만약 다음에 해당되는경우 작성된 테스트는 Unit 테스트라고 할 수 없다:
여러분을 던져 넣지 마십시오.


'''Unit Tests Vs Acceptance Tests.''' Unit 테스트는 한 조각의 기능을 캡쳐하고, 캡쳐한 기능으로 그 기능에 있는 버그를 쉽게 식별 할 수 있도록 만들어 드립니다. 가능한 많이, 실패할 가능성이 있는 각 메소드를 위해 unit 테스트들을 갖기를 시도해 보시고, 클래스당 그 테스트들 범주화를  
* ''데이터베이스와 통신하거나''
시도해 보십시오. 그럼에도 불구하고, 분명한 것은 깊이 반복되거나 또는 복합적인 셋업 상황들의 경우, 더 큰 어플리케이션에서 시나리오를 제시하는 테스트들을 작성하는 것은 보다 쉬우며, 이러한 테스트들은 수락 테스트(acceettance test) 또는 기능 테스트(fuctional tests)로 불립니다. Feather의 규칙들을 깨뜨리는 테스트들은 아마도 좋은 수락 테스트(acceptance tests)를 만들 것입니다. 테스트를 시행하는 기능에 따라 수락 테스트들을 범주화 시키십시오. 예를 들면, 만약 여러분이 컴파일러를 작성하고 있다고 하면, 각 가능한 소스 언어를 위해 만들어진 코드에 관한 assertions을 만드는 수락 테스트(acceptance test)를 작성하실 것입니다. 이러한 테스트들은 많은 클래스들을 연습해 볼 것이고 실행을 위해 긴 시간을 요구할 것입니다. 그 이유는 테스트들이 파일 시스템을 터치하기 때문입니다. 여러분은 SUnit을 사용하여 수락 테스트들을 작성할 수 있지만, 작은 변경사항들을 가할 때마다 그 테스트들을 매회 실행하는 것을 원하지는 않을 것이므로, 반드시진짜 unit 테스트들과 구별시켜야만 합니다.
* ''네트웍을 이용해서 데이터를 주고받거나''
* ''파일시스템에 접근하거나''
* ''다른 유닛테스트와 같이 실행할수 없거나<BR>또는''
* ''테스트를 진행하기 위해 (config 등의 파일을 편집하는등) 현재의 환경에 특별한 작업들을 수행해야 할 경우''
 
 
:''이런 작업들이 포함된 테스트가 항상 나쁜 것은 아닙니다. 이따금씩 이런 테스트들을 만들 필요도 있으며, Unit 테스트와 연동되는 형식으로 작성될 수 있습니다. 그렇지만 정말 중요한건 진짜 Unit 테스트와 분리해서 변경이 필요한경우 빠른 테스트셋을 유지할 수 있도록 하는거죠.''
 
 
위의 작업들이 포함된 Unit 테스트 suite 는 시간을 많이 필요로 할 수 있기때문에 이런상황은 만들지 않는것이 좋습니다.
 
 
 
'''Unit Tests Acceptance Tests.''' Unit 테스트는 기능의 일부분을 대상으로 하며, 대상이 되는 기능에 있는 버그를 쉽게 파악할 수 있도록 해줍니다. 가능하면 실패할 가능성이 많은 메서드에 대한 Unit 테스트를 만드는걸 진행해보시고, 클래스마다 테스트들에 대한 범주화를 시도해보세요. 그렇지만, 분명한 것은 깊이 반복되거나 또는 복합적인 설정 상황들의 경우에는, 응용프로그램의 시나리오를 따라가는 테스트를 작성하는게 쉽습니다; 이러한 테스트들을 허용 테스트(accepttance test) 또는 기능 테스트 라고 부르죠. Feather 의 규칙에 해당되지 않는 테스트들은 분명 좋은테스트라고 할 수 있습니다. 그리고 테스트를 시행하는 기능에 따라 허용 테스트들을 범주화 시키십시오. 예를 들어, 만약 컴파일러를 만들려고 하는경우, 대상이되는 개별 소스 언어 정책을 참고해서 제작된 코드에 대한 assertions 을 진행하는 허용 테스트를 만들 수도 있습니다. 이런경우를 대상으로 만들어지는 테스트들은 많은 클래스들을 테스트하게되며, 실행시간도 오래걸리게 되죠. 왜나하면 이런 테스트들은 파일 시스템을 건드리기 때문입니다. SUnit 을 사용하여 허용 테스트들을 작성할 수 있지만, 작은 변경 사항이 생길때마다 시간이 오래걸리는 테스트들을 매회 실행되는것은 좋지않기때문에, 이렇게 시간이 오래 걸리는 테스트는 반드시 진짜 unit 테스트들과 구별되어야 합니다.
 
 
 
'''테스트진행에 대한 Black 의 규칙.''' 시스템상의 모든 테스트들을 봤을때, 몇가지 속성을 테스트함으로서 결과를 신뢰할 수 있게 만든다는것을 알아야 합니다. 중요한 속성은 빼놓지 말고 테스트되어야 한다는것도 분명한 사실입니다. Black의 규칙은 유용한 속성에 대한 신뢰도를 높이며, 가치를 가지지 못하는 테스트는 시스템에 없어야 한다는 사실을 말합니다. 예를들자면, 같은 속성의 여러가지 테스트들은 쓸모없습니다. 사실 이런 테스트들은 대단히 해롭기까지 하죠: 이런 테스트들은 테스트들을 읽었을때 클래스의 동작을 추측하는것을 어렵게 합니다. 그리고 코드에 버그가 있는경우 한번에 많은 테스트들에 문제가 생기기 때문에 안좋기도 합니다. 테스트를 작성할 때는 이런 속성들을 주의 깊게 살펴봐야 합니다.


'''테스트의 Black의 규칙'''여러분은 시스템에서의 모든 테스트에서, 여러분의 자신감을 증가시키는 테스트를 위한 몇 가지 속성(property)을 식별할 수 있어야만 합니다. 여러분이 테스트 하지 않은 중요하지 않은 속성들이 없어야만 한다는 사실은 분명합니다. 이 규칙은 유용한 속성이 담고 있는 여러분의 자신감을 증가시켜, 시스템에 가치(value)를 더하지 않는 테스트는 없어야만 한다는 좀 명확한 사실을 진술합니다. 예를 들면 동일한 속성을 가진 여러 개의 테스트들은 어떤 유익한 작업을 수행하지 않습니다. 사실 그 테스트들은 해롭습니다: 이 테스트들은 테스트들을 읽음으로써 클래스의 동작을 추론하기 어렵게 만듭니다. 그 이유는 코드에 있는 어떤 버그가 한번에 많은 테스트들을 망가뜨리기 때문입니다. 여러분이 테스트를 작성할 때 속성을 주의 깊게 살펴보십시오.


==Notes==
==Notes==

Latest revision as of 14:36, 22 March 2013

테스트에 관한 몇 가지 조언

테스트의 작동원리는 어렵지 않습니다만, 정작 좋은 테스트를 작성하는 작업은 어렵습니다. 이 아래에 테스트를 설계 하는 방법에 대한 몇 가지 조언이 있습니다.


Unit 테스트를 위한 Feathers 의 규칙. 애자일 과정 컨설턴트이며 저자인 Michael Feathers 는 다음과 같은 주장을 했습니다.[1]


만약 다음에 해당되는경우 작성된 테스트는 Unit 테스트라고 할 수 없다:

  • 데이터베이스와 통신하거나
  • 네트웍을 이용해서 데이터를 주고받거나
  • 파일시스템에 접근하거나
  • 다른 유닛테스트와 같이 실행할수 없거나
    또는
  • 테스트를 진행하기 위해 (config 등의 파일을 편집하는등) 현재의 환경에 특별한 작업들을 수행해야 할 경우


이런 작업들이 포함된 테스트가 항상 나쁜 것은 아닙니다. 이따금씩 이런 테스트들을 만들 필요도 있으며, Unit 테스트와 연동되는 형식으로 작성될 수 있습니다. 그렇지만 정말 중요한건 진짜 Unit 테스트와 분리해서 변경이 필요한경우 빠른 테스트셋을 유지할 수 있도록 하는거죠.


위의 작업들이 포함된 Unit 테스트 suite 는 시간을 많이 필요로 할 수 있기때문에 이런상황은 만들지 않는것이 좋습니다.


Unit Tests 대 Acceptance Tests. Unit 테스트는 기능의 일부분을 대상으로 하며, 대상이 되는 기능에 있는 버그를 쉽게 파악할 수 있도록 해줍니다. 가능하면 실패할 가능성이 많은 메서드에 대한 Unit 테스트를 만드는걸 진행해보시고, 클래스마다 테스트들에 대한 범주화를 시도해보세요. 그렇지만, 분명한 것은 깊이 반복되거나 또는 복합적인 설정 상황들의 경우에는, 응용프로그램의 시나리오를 따라가는 테스트를 작성하는게 더 쉽습니다; 이러한 테스트들을 허용 테스트(accepttance test) 또는 기능 테스트 라고 부르죠. Feather 의 규칙에 해당되지 않는 테스트들은 분명 좋은테스트라고 할 수 있습니다. 그리고 테스트를 시행하는 기능에 따라 허용 테스트들을 범주화 시키십시오. 예를 들어, 만약 컴파일러를 만들려고 하는경우, 대상이되는 개별 소스 언어 정책을 참고해서 제작된 코드에 대한 assertions 을 진행하는 허용 테스트를 만들 수도 있습니다. 이런경우를 대상으로 만들어지는 테스트들은 많은 클래스들을 테스트하게되며, 실행시간도 오래걸리게 되죠. 왜나하면 이런 테스트들은 파일 시스템을 건드리기 때문입니다. SUnit 을 사용하여 허용 테스트들을 작성할 수 있지만, 작은 변경 사항이 생길때마다 시간이 오래걸리는 테스트들을 매회 실행되는것은 좋지않기때문에, 이렇게 시간이 오래 걸리는 테스트는 반드시 진짜 unit 테스트들과 구별되어야 합니다.


테스트진행에 대한 Black 의 규칙. 시스템상의 모든 테스트들을 봤을때, 몇가지 속성을 테스트함으로서 결과를 신뢰할 수 있게 만든다는것을 알아야 합니다. 중요한 속성은 빼놓지 말고 테스트되어야 한다는것도 분명한 사실입니다. Black의 규칙은 유용한 속성에 대한 신뢰도를 높이며, 가치를 가지지 못하는 테스트는 시스템에 없어야 한다는 사실을 말합니다. 예를들자면, 같은 속성의 여러가지 테스트들은 쓸모없습니다. 사실 이런 테스트들은 대단히 해롭기까지 하죠: 이런 테스트들은 테스트들을 읽었을때 클래스의 동작을 추측하는것을 어렵게 합니다. 그리고 코드에 버그가 있는경우 한번에 많은 테스트들에 문제가 생기기 때문에 안좋기도 합니다. 테스트를 작성할 때는 이런 속성들을 주의 깊게 살펴봐야 합니다.


Notes