TDD 주기
1. 테스트 작성
올바른 답을 얻기 위한 모든 요소를 포함 시킬 것.
2. 실행 가능하게 만들기
가능한 빨리 테스트를 통과 시키는 코드를 작성한다. 이를 위해서 중복코드, 상수 반환 등을 해도 좋다.
3. 올바르게 만들기
2에서 발생한 코드 중복을 제거하고, 상수나 stub으로 구현되어 있는 부분을 실제 구현으로 바꾼다.
TDD vs Architecture-Driven Development
'작동하는' '깔끔한' 코드를 위해 TDD에서는 '작동하는'을 우선적으로 해결하고 ADD에서는 '깔끔한'을 먼저 해결한다.
프로덕트 관점에서 볼 때 조금 덜 깔끔하더라도 일단은 요구사항대로 작동하는게 더 중요하지 않을까라는 생각이 들긴 하는데 아직은 정확한 장단점을 모르겠다.
TDD의 경제성
TDD로 구현할 땐 테스트 코드의 줄 수와 모델 코드의 줄 수가 거의 비슷한 상태로 끝난다. TDD가 경제적이기 위해서는 매일 만들어 내는 코드의 줄 수가 두 배가 되거나 동일한 기능을 구현하되 절반의 줄 수로 해내야 할 것이다. TDD가 자신의 방법에 비해 어떻게 다른지 직접 측정해 보아야 할 것이다. 이때 디버깅, 통합 작업, 다른 사람에게 설명하는 데 걸리는 시간 등의 요소를 반드시 포함해야 한다.
TDD를 한다는 것은 테스트 코드 작성 시간, 리팩토링 시간 등을 생각했을 때 전체적으로 공수가 더 들어갈 수 밖에 없는 것 같다. 다만 TDD로 짜여진 코드의 신뢰도?가 그것을 상쇄한다는 것일까? 문득 생각보다 러닝커브가 크겠다라는 생각이 든다.
Tips
- 큰 테스트를 공략할 수 없으면 작은 테스트를 만들자.
- 중복을 만들어서라도 최대한 빨리 돌아가게 만들되 중복이 사라지기 전까진 집에 갈 수 없다!
- 지원 테스트가 갖춰지지 않은 리팩토링을 하게 된다면 우선 테스트를 작성하자.
- 결함이 보이면 테스트를 작성하자.
- 더 많은 동기가 있기 전에 더 많은 설계를 도입하지 말자.
- 테스트가 통과되지 않는 상태에서 테스트를 추가로 작성하지 말자.
- 리팩토링하는 단계의 크기를 조절하는 것이 포인트. 답답하면 좀 더 크게, 불안 하다면 좀 더 작게.
