단위 테스트 프레임워크에 어느 정도 익숙해져 가독성과 유지 보수성이 좋고 신뢰도가 높은 테스트를 작성하는 방법을 깨우쳤다면 그다음은 언제 테스트를 작성해야 할지 아는 것이다. 하지만 여전히 현실은 선 개발 후 테스트를 진행하는 경우가 많다. 많은 개발자가 단위 테스트를 작성하기에 가장 좋은 시기를 기능을 먼저 구현한 다음이나 코드를 머지(merge)하기 직전이라고 생각한다.

솔직히 말해 아직까지도 테스트를 그다지 믿음직스럽게 생각하지 않는 개발자들이 있다. 그러나 실제로 코드 리뷰 단계에서 테스트 없이는 코드가 통과되지 않거나, 테스트가 없어 코드 머지 후에 버그가 발생하는 등 문제를 겪으면서 테스트가 왜 필요한지 깨닫는다. 그러다 코드 리뷰를 통과하고 메인 브랜치에 코드를 병합하기 위해 결국 테스트를 작성하게 된다. 예를 들어 어떤 개발자가 새로운 기능을 추가한 후 코드 리뷰를 요청했을 때, 코드 리뷰어가 “이 기능에 대한 단위 테스트가 없으면 이 코드를 합칠 수 없습니다.”라고 리뷰를 남겼다고 가정해 보자. 풀 리퀘스트(pull request)를 올린 개발자는 그제야 테스트를 추가하여 코드 리뷰를 통과하려고 할 것이다(이러한 현실은 영양가 없는 테스트를 양산하는 원인이 되며, 이는 3장에서 다룰 예정이다).