TDD(Test-driven Development)는 코드를 작성하기 전에 테스트를 쓰는 소프트웨어 개발 방법론이다. 다시 말해, 개발자 자신이 바람직하다고 생각하는 코드의 결과를 미리 정의하고, 이것을 바탕으로 코드를 작성하는 방법이다.
TDD의 개발 주기를 그림으로 나탄태면 아래와 같이 총 3단계로 이루어진다.
이 과정에서 Write Faling Test 과정을 마치기 전에 Make Test Pass의 작업을 시작하지 않도록 주의해야 한다. 또한 Make Test Pass 를 진행할 때는, Write Faling Test 의 테스트를 통과할 정도의 최소 코드만 작성해야 한다.
테스트를 먼저 작성하는 것은 필연적으로 코드를 어떻게 구성할지 고민하게 된다는 것을 의미하고, 결과적으로 버그가 더 적은 코드를 짤 수 있게 된다. 또, 불필요한 설계를 피할 수 있고, 테스트 코드의 요구 사항에 집중할 수 있게 된다. 일반적으로 TDD를 따라 소프트웨어를 개발할 경우 그렇지 않은 경우보다 결함을 50 ~ 90% 까지 감소시킬 수 있습니다.
이처럼 버그가 적은, 보다 효과적인 코드를 짤 수 있는 방법임에도 불구하고, 실제로 완전한 TDD를 따르는 개발자는 의외로 많지 않다. 그 이유는 대부분의 개발자들이 생각하고 일하는 방식과 일치하지 않기 때문이다. 대부분의 개발자는 테스트를 작성하는 것보다, 만들어야 하는 것을 바로 코드로 작성하는 방식이 훨씬 자연스럽고 빠르다고 느끼기 때문이다.
코드를 작성하기에 앞서 테스트 코드를 먼저 작성해야 하기 때문에 시간이 오래 걸리는 것처럼 느껴지지만, 오히려 예상하지 못했던 버그를 줄여 소요 시간을 줄일 수 있기 때문이다.
개발 과정에서 코드는 다양한 조건에 의해 계속해서 삽입, 수정, 삭제되는 이 과정에서 코드가 중복되거나 불필요한 코드가 남게 되어 여러 가지 버그가 발생하거나, 디버깅 또한 어려워지는 현상이 발생하기도 합니다. 결국 그런 코드를 유지보수하기 위해서는 처음 개발할 때 아꼈던 리소스보다 더 많은 리소스를 투입해야 하는 경우가 발생할 수 있다.
그럼에도 불구하고 TDD를 사용하는 이유는 무엇일까요? 코드를 작성하기에 앞서 테스트 코드를 먼저 작성해야 하기 때문에 시간이 오래 걸리는 것처럼 느껴지지만, 오히려 예상하지 못했던 버그를 줄여 소요 시간을 줄일 수 있기 때문입니다. 개발 과정에서 코드는 다양한 조건에 의해 계속해서 삽입, 수정, 삭제됩니다. 이 과정에서 코드가 중복되거나 불필요한 코드가 남게 됩니다. 그리고 그로 인해 여러 가지 버그가 발생하거나, 디버깅 또한 어려워지는 현상이 발생하기도 합니다. 결국 그런 코드를 유지보수하기 위해서는 처음 개발할 때 아꼈던 리소스보다 더 많은 리소스를 투입해야 하는 경우가 발생합니다.