1997년만 해도 TDD(Test Driven Development)라는 개념을 아무도 몰랐다.

우리들 대다수에게 단위 테스트란 자기 프로그램이 ‘돌아간다’는 사실만 확인하는 일회성 코드에 불과했다.

TDD 법칙 세 가지

1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다
2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다
3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다

위 세 가지 규칙을 따르면 개발과 테스트가 대략 30초 주기로 묶인다.

테스트 코드와 실제 코드가 함께 나올 뿐더러 테스트 코드가 실제 코드보다 불과 몇 초 전에 나온다.

이렇게 하면 매일 수십 개, 매달 수백 개, 매년 수천 개에 달하는 테스트 케이스가 나오고, 실제 코드를 사실상 전부 테스트하는 테스트 케이스가 나온다.

하지만 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 한다.

깨끗한 테스트 코드 유지하기

지저분한 테스트 코드가 테스트를 안 하는 것보다 못하다.

실제 코드가 진화하면 테스트 코드도 변해야 한다. 그런데 테스트 코드가 지저분할수록 변경하기 어려워진다.

실제 코드를 변경해 기존 테스트 케이스가 실패하기 시작하면, 지저분한 코드로 인해 실패하는 테스트 케이스를 점점 더 통과시키기 어려워진다. 그래서 테스트 코드는 계속해서 늘어나는 부담이 되버린다.

새 버전 출시 때마다 테스트 케이스 유지 보수 비용도 늘어난다.