서론

Before TDD …

내가 TDD를 배우기 전에 개발했던 방식은 다음과 같았다.

1. 만들 기능에 대해서 설계를 고민한다.
   1. 어떤 클래스, 인터페이스가 필요할 지 고민하고 어떤 메소드가 들어갈지 오랜시간 고민한다.
2. 과정 1을 수행하면서 구현에 대해서도 고민한다.
3. 바로 코드를 작성한다.
   1. 리펙토링은 나중에 하기로 한다 (!!!!)
4. 서버를 구동한 후, PostMan으로 원하는 결과가 나오는지 확인한다.
   1. 오류나, 원하는 결과가 나오지 않는다면 원하는 결과가 나올때까지 코드를 수정한다.

위 같은 과정으로 코드를 작성하다보니, 오류가 발생하면 찾는데도 오래 걸렸으며 완성된 코드 조차 깔끔(클린)하지 못했다. 구현 시간이 촉박하다는 핑계로 테스트를 소홀히 하다보니 다양한 케이스에 대한 예외처리도 많이 놓쳤던 것 같다. 무엇보다도 시간이 부족하여 테스트를 작성하지 않았다고 했지만, 테스트를 하지 않아도 개발 시간이 꽤 오래 걸렸다.

TDD를 배우기 전 했던 고민들

• 테스트 단위는 어느 정도로 ?
• 테스트 할때 다른 클래스에 대한 의존도가 너무 높은데 ?
• 실제 DB를 사용하려니 부담 스러운데 ?
• …

요즘 인기를 끌고있는 개발 기법 TDD를 나 역시 이게 뭔지 들었던 기억이 있다.

‘테스트를 먼저 작성하고 구현’ 이라고 해서 독특하다고 생각했는데, 구현 코드가 없는데 어떻게 테스트를 할 수 있는거지? 라는 질문이 나의 호기심을 자극했고, 이것이 내가 TDD를 배우게 된 계기가 되었다.

본론

TDD란?

TDD는 테스트부터 시작한다. 구현을 먼저하고 나중에 테스트 하는 것이 아니라, 먼저 테스트를 하고 그 다음에 구현한다. 여기서 테스트를 먼저 한다는 것은 기능이 올바르게 동작하는지 검증하는 테스트 코드를 작성한다는 것을 의미한다. 기능을 검증하는 테스트 코드를 먼저 작성하고 테스트를 통과하기 위해 개발을 진행한다.