SqueakByExample:7.9

테스트에 관한 몇 가지 조언

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

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

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

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

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

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

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

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