작성하려는 코드가 있따면 항상 먼저 어떻게 그 코드를 테스트할지 고민해야한다.
코드를 작성한 후에 어떻게 테스트할지 고민하기보다 작성할 코드를 묘사하는 테스트를 설계해야한다.
이것이 테스트 주도 개발에 기반을 둔 단위 테스트 전략의 핵심이다.
TDD에서 단위 테스트를 시스템의 모양을 잡고 통제하는 도구로 활용해야 한다.
단위 테스트는 소프트웨어를 어떻게 만들어야 할지에 관한 잘 훈련된 사이클의 핵심적인 부분이다.
따라서 TDD를 채택하면 소프트웨어 설계는 달라지고 아마 더 좋아질 것이다.
(1) TDD의 주된 이익
코드를 깨끗하게 유지하도록 치열하게 싸우지 않으면 시스템은 대개 점점 퇴화한다.
TDD에서는 코드가 변경될 것이라는 두려움을 지울 수 있다.
리펙토링은 위험 부담이 있는 일이기도 하고 우리는 일견 위험하지 않아 보이는 변경을 할 때도 실수를 많이 한다.
하지만 TDD를 잘 따르면 실질적으로 모든 사례에 대해 단위테스트를 작성하게 된다.
→ 단위테스트는 코드를 지속적으로 발전 시킬 수 있는 자유를 준다.
실패하는 테스트 코드 작성하기 → 테스트 통과시키기 → 이전 두 단계에서 추가되거나 변경된 코드 개선하기
테스트 작성 → 최소한으로 프로덕션 코드 고쳐 테스트 통과되게 만들기 → git 커밋