본문에 TDD는 많은데 정작 TDD와 무슨 관계가 있는 글인지는 잘 모르겠네요;
TDD관련 내용 덧붙이고 갑니다. 참고하시길
1. 테스트 범위
작년 오키에서 주최한 TDD 세미나에서 나온 질문 중 이런 것이 있었습니다.
왜 TDD 하는 사람들은 모든 코드를 다 단위 테스트 하지 않으면 나쁘다고 말하느냐?
저는 당시 토론 사회를 맡았는데 패널 두 분과 저 세명은 같은 답을 했습니다.
누가 그러더냐? 우린 안그러는데?
=> Test everything that could possibly break. (XP) 가 원칙으로 알려져 있죠.
- You should test things that might break. If code is so simple that it can't possibly break, and you measure that the code in question doesn't actually break in practice, then you shouldn't write a test for it... XP explained, Kent Beck
- TDD's view of testing is pragmatic. In TDD, the tests are a mean to an end - the end being code in which we have great confidence. If our knowledge of the implementation gives us confidence even without a test, then we will not write that test. TDD by example, Kent Beck
- .. Not worth the investment? You've got to be kidding me! How could anyone NOT want that suite of tests? Do yourself a favor and stop quibbling over silliness. Uncle Bob
2. 설계에 자신이 없다면 TDD 하지 않는 것이 낫다?
그러니 설계에 자신이 없다면 TDD 하지 않는 것이 낫습니다. 반대로 설계 역량이 높을수록 TDD 비용은 줄어듭니다. 당장 설계 역량이 부족한데 TDD를 할 필요는 없습니다. 불필요한 시간 낭비 하지말로 수동 테스트 한 다음 남는 시간에 설계 공부하는 것이 현명합니다.
=> TDD 수행에 있어 설계 역량이 필요하다는 내용은 본적이 없습니다. 오히려 자신감이 없기에 TDD를 하라고 되어 있죠
- TDD는 더 깔끔한 설계를 할 수 있도록, 그리고 더 많은 것을 배워감에 따라 설계를 더 개선할 수 있도록, 적절한 때 적절한 문제에 집중할 수 있게끔 도와준다, TDD by example, Kent Beck
- 기능을 추가할 때 어떤 설계가 좋을지 고민하지 않고, 할 수 있는 한 가장 쉽게 테스트를 통과시키려고만 노력한다, 마틴 파울러
- Testing Improves Code. An example showing how writing some tests can help you to improve the code.
- 마이크로 레벨에서 TDD는 설계에 도움을 주지만 매크로 레벨에서 설계를 향상시키는 것은 별개란 내용도 어디선가 봤던 기억이 있네요