디버깅은 순간이지만 테스트는 남는다.
디버거가 디버깅 방법 중에서 가장 강력한 것임에는 틀림없다. 우리 모두는 디버거가 손에 익도록 해야 한다. 하지만 나같은 경우에는 디버거를 점점 안 쓰게 됐다. 그리고 나만 그런 것도 아니었다. 비슷한 얘기를 하는 개발자들이 많았다. 왜 이런 일이 벌어지는 걸까?
변화의 중심에는 테스트 우선 개발이 있다. 예전에는 디버깅하면 디버가가 떠올랐다면 요즘에는 테스트 작성이 떠오른다.
테스트는 이론이 맞음을 증명해 보여줄 뿐만 아니라 버그가 제대로 수정됐는지도 검증해준다.
자, 테스트 없는 코드를 어떻게 리팩토링할 수 있을까? 못한다. 먼저 테스트를 작성하자.
예를 들어 지금 이 순간 AspectJ의 테스트 세트와 완전한 실제 코드 세트 가운데 한 가지만 선택해서 가질 수 있다면 어떤 것을 선택할 거냐는 것이었죠. 이 곤란한 질문을 생각하면 살수록 — 사실 두 가지 모두 잃고 싶지 않지만 — 테스트 세트를 선택해야겠다는 생각이 듭니다.
Adrian Colyer
잘 작성된 테스트 코드는 깊이를 가늠하기 힘든 거대한 늪이 아니거든요. 엄청 단순하며 작은 메소드에 코드는 너댓 줄 정도죠 … 테스트 코드를 작성하는데 걸리는 시간이 산술급수로 증가하면 어려운 버그를 찾아내는데 걸리는 시간은 기하급수로 증가합니다. … 단위 테스트는 시스템의 행동 양식을 정의하고 있죠. 기능적 동작명세(functional working specficiation)라고나 할까요. 지적 재산권의 관점에서 본다는 그것이 훨씬 더 가치 있습니다. 그것만 있으면 소스코드는 다른 방법으로 얼마든지 재창조가 가능하거든요.
앤디 헌트
리팩토링을 하지 않을 때에도 잘 짜여진 테스트는 프로그래밍을 빠르게 한다는 것을 알게 되었다.
한 벌의 테스트는 버그를 찾는데 걸리는 시간을 엄청나게 단축시키는 강력한 버그 탐지기이다.
테스트로 모든 버그를 잡을 수 없다는 걱정 때문에 대부분의 버그를 잡을 수 있는 테스트를 작성하는 것을 멈추지 마라.
완전한 테스트를 실행시키지 않는 것보다는 불완전한 테스트라도 작성하고 실행시키는 것이 더 낫다.