TDD 법칙 세 가지
첫째 법칙: 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
둘쨰 법칙: 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
셋째 법칙: 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
하지만 팀은 지저분한 테스트 코드를 내놓으나 테스트를 안 하나 오십보 백보라는, 아니 오히려 더 못하다는 사실을 깨닫지 못했다. <p.156>
깨끗한 테스트가 따르는 다섯 가지 규칙(F.I.R.S.T)
빠르게(Fast): 테스트는 빨라야 한다. 느리고 자주 돌리지 못하는 테스트는 초반에 문제를 찾아내 고치지 못하고 결국 코드 품질이 망가진다.
독립적으로(Independent): 각 테스트는 서로 의존하면 안 된다. 테스트가 서로에게 의존하면 하나가 실패할 때 나머지도 잇달아 실패하므로 원인을 진단하기 어려워지며 후반 테스트가 찾아내야 할 결함이 숨겨진다.
반복가능하게(Repeatable): 테스트는 어떤 환경에서도 반복 가능해야 한다.
자가검증하는(Self-Validating): 테스트는 부울(bool) 값으로 결과를 내야 한다. 테스트가 스스로 성공과 실패를 가늠하지 않는다면 판단은 주관적이 되며 지루한 수작업 평가가 필요하게 된다.
적시에(Timely): 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다. 실제 코드를 구현한 다음에 테스트 코드를 만들면 실제 코드가 테스트하기 어렵다는 사실을 발견할지도 모른다.
테스트 코드는 실제 코드의 유연성, 유지보수성, 재사용성을 보존하고 강화하기 때문이다. 그러므로 테스트 코드는 지속적으로 깨끗하게 관리하자. <p.168>
테스트 코드에 대해서 짧게 나마 배워 볼 수 있었다. 하지만 나는 실제로 테스트 코드를 작성해본 적이 없다. 저자는 마지막에 "사실상 깨끗한 테스트 코드라는 주제는 책 한 권을 할애해도 모자랄 주제다." 라고 이야기한다. 그리고 읽다보면 마치 테스트 코드가 실제 코드보다 중요한 것 처럼 느껴지기도 한다.
그냥 코드를 작성하기도 바쁜데 테스트 코드까지 상세하게 작성해야 한다니 한숨부터 나온다. 하지만 이 장을 읽어보면 한숨을 쉴때가 아니라는 것을 깨닫는다. 테스트 코드가 주는 그 효용성이 상당하기 떄문이다. 앞에서도 이야기했듯 코드는 변한다. 상황이 변하면 코드도 변화고 시간이 지나면 또 코드도 변한다. 아직 많은 코드를 본 것은 아니지만 영원한 코드는 없는 것 같이 보인다. ( 시대가 계속해서 발전한다면 ) 그렇다면 완성된 코드, 돌아가는 코드는 정말로 완성되었다고 이야기할 수 있을까? 끝없는 유지보수와 업데이트가 프로그램을 기다리고 있다.
이런면에서 테스트 코드의 중요성이 더욱 부각되는 거 같다. 테스트 코드의 테도 모르는 입장이었지만 적어도 그 중요성과 효용성에 대해서는 확실하게 이해한 거 같다. 앞으로 코드를 작성하면서 이것들을 나지막하게라도 생각하면서 작성한다면 큰 도움이 될 것 같다.