글
단위 테스트에 관한 흥미로운 글
2008/소프트웨어 테스트
2008/11/21 07:30
테스트 스위트를 어떻게 정리할까 고민하고 있는데 관련 글이 올라왔다.
My Unified Theory of Bugs
이 그에서는 테스트를 세 가지로 분류했다. 실용적인 분류다. 내가 즉흥적으로 메모한 분류와도 일맥한다.
- 클래스 수준의 단위 테스트
- 리소스나 DB 값을 확인하기 위한 테스트
- 설정 정보를 확인하기 위한 테스트
- 성능 테스트
일찌기 Scott Ambler는 시계열까지 동원해서 훨씬 더 복잡하게 테스트를 정리한 바 있다.
Miško Hevery는 테스트 하기 좋은 코드(Testable code)가 갖춰야 하는 요건으로 다음과 같은 사항을 제시하면서 다른 글을 소개한다:
읽고 보니 그렇다. 테스트를 하지 않고 머리속으로 테스트 하기 좋은 코드를 작성하거나, 작성한 뒤에 테스트를 하면서 수정하기 보다는 당연히 먼저 테스트를 할 때 테스트 하기 좋은 코드를 작성하기가 수월할 것이다. :)
2008.11.21 점심 시간 추가:
My Unified Theory of Bugs
이 그에서는 테스트를 세 가지로 분류했다. 실용적인 분류다. 내가 즉흥적으로 메모한 분류와도 일맥한다.
- 클래스 수준의 단위 테스트
- 리소스나 DB 값을 확인하기 위한 테스트
- 설정 정보를 확인하기 위한 테스트
- 성능 테스트
일찌기 Scott Ambler는 시계열까지 동원해서 훨씬 더 복잡하게 테스트를 정리한 바 있다.
Miško Hevery는 테스트 하기 좋은 코드(Testable code)가 갖춰야 하는 요건으로 다음과 같은 사항을 제시하면서 다른 글을 소개한다:
- Clear separation between classes (Testable Seems) --> clear separation between classes makes it less likely that a wiring problem is introduced. Also, less code per class lowers the probability of logical bug.
- Dependency Injection --> makes wiring explicit (unlike singletons, globals or service locators).
- Clear separation of Logic from Wiring --> by having wiring in a single place it is easier to verify.
I find that a lot of people claim that they write unit-tests, but upon
closer inspection it is a mix of functional (wiring) and unit (logic)
test. This happens becuase people wirte tests after code, and therefore
the code is not testable.
읽고 보니 그렇다. 테스트를 하지 않고 머리속으로 테스트 하기 좋은 코드를 작성하거나, 작성한 뒤에 테스트를 하면서 수정하기 보다는 당연히 먼저 테스트를 할 때 테스트 하기 좋은 코드를 작성하기가 수월할 것이다. :)
2008.11.21 점심 시간 추가:
간혹 그런 경우가 있습니다. 거의 완성이 되어가는데 결과가 조금 이상합니다. 이리 바꿔보고 저리 바꿔보고 하다보니 어느샌가 잘
동작합니다. 저는 이런 경우, 코드에 끌려왔다라고 표현합니다. 하지만 TDD로 개발할 때는 자신이 통제하지 못하는 상황에서
앞으로 나아가기가 어렵습니다.
출처: 테스트 수준은 개발 수준을 드러낸다
출처: 테스트 수준은 개발 수준을 드러낸다
