SqueakByExample:7.9

테스트에 관한 몇 가지 조언

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

Unit 테스트를 위한 Feathers의 규칙. Agile process 컨설던트이며 저자인 Michael Feathers는 다음과 같이 썼습니다.

만약 다음과 같을 경우 테스트는 Unit 테스트가 아니다:

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

너무나 시간이 많이 걸리므로, Unit 테스트 슈트 실행을 원하지 않는 상황에 여러분을 던져 넣지 마십시오.

Unit Tests Vs Acceptance Tests. Unit 테스트는 한 조각의 기능을 캡쳐하고, 캡쳐한 기능으로 그 기능에 있는 버그를 쉽게 식별 할 수 있도록 만들어 드립니다. 가능한 많이, 실패할 가능성이 있는 각 메소드를 위해 unit 테스트들을 갖기를 시도해 보시고, 클래스당 그 테스트들 범주화를 시도해 보십시오. 그럼에도 불구하고, 분명한 것은 깊이 반복되거나 또는 복합적인 셋업 상황들의 경우, 더 큰 어플리케이션에서 시나리오를 제시하는 테스트들을 작성하는 것은 보다 쉬우며, 이러한 테스트들은 수락 테스트(acceettance test) 또는 기능 테스트(fuctional tests)로 불립니다. Feather의 규칙들을 깨뜨리는 테스트들은 아마도 좋은 수락 테스트(acceptance tests)를 만들 것입니다. 테스트를 시행하는 기능에 따라 수락 테스트들을 범주화 시키십시오. 예를 들면, 만약 여러분이 컴파일러를 작성하고 있다고 하면, 각 가능한 소스 언어를 위해 만들어진 코드에 관한 assertions을 만드는 수락 테스트(acceptance test)를 작성하실 것입니다. 이러한 테스트들은 많은 클래스들을 연습해 볼 것이고 실행을 위해 긴 시간을 요구할 것입니다. 그 이유는 테스트들이 파일 시스템을 터치하기 때문입니다. 여러분은 SUnit을 사용하여 수락 테스트들을 작성할 수 있지만, 작은 변경사항들을 가할 때마다 그 테스트들을 매회 실행하는 것을 원하지는 않을 것이므로, 반드시진짜 unit 테스트들과 구별시켜야만 합니다.

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