TDD란?
Test Driven Development. 테스트 주도 개발이다.
보통 '~~ 주도 개발' 이라고 이름이 붙으면, 개발할 때 '~~' 를 1순위로 여기며 개발하는 방법론을 의미한다.
즉, 테스트 주도 개발은 테스트를 1순위로 여기며 개발하는 개발 방법론이다.
개발 방법론!
어떻게 하나?
결론: 테스트 코드 작성 -> 프로덕션 코드 작성 -> 리팩터링 순으로 진행한다.
1. 테스트 코드 작성
우선 구현하려는 기능에 대해 단위 테스트를 작성한다.
작성하고 돌리면 당연히 실패한다. 왜? 아직 프로덕션 코드가 없으니까.
어쩌면 컴파일 조차 안될 것이다.
2. 프로덕션 코드 작성
이제 기능을 구현한다.
테스트 코드와 프로덕션 코드를 이상없이 작성했다면 테스트가 통과할 것이다.
이때 중요한 점은, 코드 품질은 신경쓰지 않아도 된다.
3. 리팩터링
코드 품질은 이제 신경쓴다.
돌아가는 쓰레기를 만들었다면, 이제 이쁜 쓰레기로 만들 차례이다.
테스트 코드, 프로덕션 코드 모두 리팩터링을 진행한다.
왜 하나?
TDD를 해본 경험으로 이야기하자면, 버그가 생길 확률이 현저하게 떨어진다.
(높은 테스트 커버리지는 덤)
확실히 테스트 코드로 내가 구현하려는 기능에 대해 확실한 안전 장치를 걸고 기능을 추가하니까, 아무래도 안전하다.
구현하려는 기능에 대한 도메인 이해도가 어느 정도 있고, 주어진 시간이 충분하다면 나는 TDD를 가급적 할 것이다.
주변 지인들에게도 추천할 것이다.
단점은?
기능을 작성하는 데까지 시간이 오래 걸린다.
아무래도 돌다리르 건널 때 두들겨보고 건너는 개념인데, 이 두들기는 시간이 상당하다.
체감 상 바로 프로덕션 코드를 작성할 때에 비해 2~3배는 걸리는 것 같다.
또, 내가 구현하려는 기능에 대해 설계 방법이나 감이 잘 오지 않거나 개발 초기 단계라서 변화가 매우 빠른 상황이라면 나는 비추한다.
TDD는 테스트 코드를 필연적으로 낳게 되는데, 이 테스트 코드는 위 상황에서는 걸림돌이기 때문이다.
TDD는 개발 방법론일 뿐이니 너무 맹신하지말자.
무엇이든 상황에 맞게 판단하자.
착각하기 쉬운 것
프로젝트에 TDD를 적용한다고 했을 때, 항상 모든 기능에 대해 테스트 코드를 먼저 작성할 수 없다.
물론 구현하려는 기능에 대해 분명하고 확실한 상황이라면 TDD를 적용할 수 있지만, 개발이라는 게 처음 생각한대로 구현하다보면 생각지도 못한 기능을 함께 구현해야 하는 경우가 종종 있다.
따라서 TDD를 처음 시도해보려는 사람들이 혹여나 "테스트 코드를 먼저 작성하기 전까지는 기능 구현 안할거야 !!" 라는 생각을 가질 수 있다고 생각한다.
본인이 구현하려는 기능이 무엇인지 분명히 아는 선에서, TDD를 적용하는 것이 바람직해보인다.