<aside> 💡 Test-Driven Development 혹은 Test First Development + Refactoring
</aside>
흔히들 테스트 주도 개발을 선후 관계없이 테스트만 작성하면 TDD로 알고 있는 사람과, 단위테스트는 TDD다 정도로만 알고 있는 사람이 많다. 책에서는 다음과 같이 TDD를 설명하고 있다.
TDD란 프로그래밍 의사결정과 피드백 사이의 간극을 의식하고 이를 제어하는 기술
TDD는 테스트 기술이 아닌 분석기술이자 설계 기술
이를 내 지식선에서 좀 더 쉽게 정리해보자면, 기능 개발에 앞서 기능을 가정하고, 그 가정에 대한 테스트를 작성하며 테스트가 통과하도록 만들고, 이를 개선하는 짧은 간격으로 반복하는 것을 TDD라고 생각한다.
그럼 이런 방식이 어떠한 장점이 있을까? 그냥 바로 기능부터 구현하면 생산성이 더 높아지지 않을까 생각할 수 있다. 하지만, OOP 패러다임을 기억하고 있다면, 객체간에는 메세지만을 주고받도록 설계하고, 각각의 객체간의 결합도를 낮추고 응집도를 높혀야 한다는 것을 기억할 것이다.
테스트 코드의 선행 작성은 이런 부분에서 하나의 기능에 대해 의존성을 파악하기가 쉽다.
특정 도메인의 기능을 테스트하려 할 때 이 도메인이 의존하고 있는 다른 객체가 많을 수록, 필요로 하는 매개변수 로직이 많아질수록 테스트는 힘들어질 것이다. 위에서 말했듯이 TDD의 핵심은 짦은 간격의 테스트 사이클을 반복하는 것인데, 이렇게 테스트 작성의 간격을 넓힉게 되는 코드를 만난다면 해당 코드가 어떠한 문제가 있다는 것을 알 수 있다. 그리고 이런 지점을 빨리 파악 할 수록, 완성도있는 코드로 도달하는 시간은 짧아질 수 있다.