참고: 위키백과, TDD(테스트 주도 개발)란

테스트 주도 개발(Test-driven development TDD)은 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스 중 하나이다. 테스트가 개발을 이끌어 나가는 테스트 주도의 개발이라고 할 수 있다.

예전에 부트캠프에서 유닛 테스트를 배울 때, 멘토님들이 만드는 사이트는 개발을 하기 전에 테스트 코드를 먼저 작성했다고 했다. 그게 굉장히 신기하고 너무 검증에 초점이 맞춰진 개발 방식이 아닌가 했는데, 실제 구직을 하다 보니 TDD 방식으로 진행하는 회사가 굉장히 많았다.

이 게시물도 채용 상세에 TDD가 하도 많이 적혀 있어서 간단하게 정리해보는 글이라고 할 수 있다.

개발자는 먼저 요구사항을 검증하는 자동화된 테스트 케이스를 작성한다. 그런 후에, 그 테스트 케이스를 통과하기 위한 최소한의 코드를 생성한다. 마지막으로 작성한 코드를 표준에 맞도록 리팩토링한다. 이 기법을 개발했거나 '재발견' 한 것으로 인정되는 Kent Beck은 2003년에 TDD가 단순한 설계를 장려하고 자신감을 불어넣어준다고 말하였다.

TDD가 필요할 때

여러 번 해봤거나, 결과를 충분히 알 수 있는 경우라면 TDD를 하지 않아도 된다. 다만 내부, 외부적으로 불확실성이 높을 때에는 굉장히 효과적이다.

• 처음해보는 주제
• client의 요구가 달라질 수 있을 때
• 코드가 많이 바뀌어야 할 때
• 누가 유지보수를 해야하는지 모를 때

협업에 용이한 이유

• 남이 짠 코드를 쉽고 빠르게 이해할 수 있다.
• 남이 짠 코드를 고치더라도 결과가 증명해주기 때문에, 남이 짠 코드를 만지는데 위험 부담을 줄여준다.

장단점

• TDD를 하게 되면 개발 시간은 늘어난다.
• 하지만 그만큼 결함이 줄어드게 된다.
• 깨끗한 코드가 나올 확률이 높아진다.
• 유지보수 비용이 낮아진다.