Guidelines for Better Unit Tests TDD2009. 7. 29. 15:04
http://www.infoq.com/news/2009/07/Better-Unit-Tests
Jimmy Bogard는 “Getting value out of your unit tests” 라는 아티클에서 다음과 같은 3가지 규칙을 명시했다.
1. 테스트 이름은 사용자 입장에서 무엇/왜를 기술해야 한다. - 개발자가 테스트의 이름을 보면 의도된 행위가 무엇인지 이해할 수 있어야 한다.
2. 테스트도 코드이다. 테스트에도 사랑을 나눠주라. - 운영코드만 리팩토링해야 하는것이 아니다. 읽기 좋은 테스트는 유지보수하기 쉽고, 다른 사람이 이해하기 쉽다. 길고, 복잡한 테스트를 좋아하는 사람은 없다. 테스트에 30 라인이 넘는 셋업 코드가 있다면 해당 코드를 생성 메소드로 분리하라. 긴 테스트 코드는 개발자를 당혹스럽게 한다. 운영코드에 긴 메소드가 있으면 리팩토링하면서 왜 긴 테스트는 코드는 내버려두는가 ?
3. “Don’t settle on one fixture pattern/organizational style” – Sometimes the standard pattern of one class, one test fixture doesn’t work.
Lior Friedman는 테스트의 첫번째 원칙은 내부 구조가 아니라 외부적인 행위를 테스트하는 것이라고 한다. 달리 표현한다면 해당 클래스에 대한 현재 구조가 아니라 기대치를 테스트하라는 것이다.
Ravichandran Jv는 아래와 같은 자신의 규칙을 언급했다.
1. 가능한 하나의 테스트에 하나의 Assert
2. test 메소드 내에 if/else가 존재한다면 분기문을 다른 개별 테스트 메소드로 분리하라.
3. 테스트 대상 메소드에 if/else가 존재한다면, 이 메소드도 리팩토링 대상이다.
4. 메소드의 이름은 어떤 테스트인지를 나타내야 한다. ex. TestMakeReservation와 TestMakeNoReservation는 다르다.
NUnit의 저자인 Charlie Poole도 하나의 테스트방 하나의 Assert를 언급했다.
Bryan Cook은 아래와 같은 고려할 만한 테스트 관련 목록을 만들었다:
DO: Name Fixtures consistently
DO: Mimic namespaces of Target Code
DO: Name Setup/TearDown methods consistently
CONSIDER: Separating your Tests from your Production Code
DO: Name Tests after Functionality
CONSIDER: Use "Cannot" Prefix for Expected Exceptions
그리고 이상과 같은 모든 이슈들은 Gerard Meszaros의 “xUnit Test Patterns: Refactoring Test Code”이라는 책에 집대성된다.
