Overview
TDD(Test-driven Development)는 코드를 작성하기 전에 테스트를 쓰는 방법론입니다. 개발자 자신이 바람직하다고 생각하는 코드의 결과를 미리 정의하고, 이것을 바탕으로 코드를 작성하는 법입니다.
Pros
실제 코드보다 테스트를 먼저 작성한다는 것은, 이미 내가 바람직한 코드가 무엇이고, 어떻게 작성해야 되는지에 대한 고민이 이미 끝났다는 의미입니다. 즉, 테스트를 먼저 작성하는 개발은 필연적으로 코드를 어떻게 구성할지 고민하고, 그 과정에서 버그가 더 적은 코드를 짜게 됩니다. 테스트가 쉽도록 코드의 구조를 기획(Design)하는 것도 같은 효과를 내게 됩니다.
Cons
TDD는 프로그래머들이 자연스럽게 생각하고 일하는 방식과 일치하지 않습니다. 소프트웨어는 집을 건축하는 것과는 달리 더 유동적입니다. 아마 대부분의 프로그래머는 테스트를 작성하는 것보다 바로 뭔가 만들어내고 싶어 할 것입니다.
같은 맥락에서 또 살펴보면, 코드를 기획한다는 것은 초반에 명확하지 않을 수 있고 대신 빠르게 프로토타입을 만들어 전반적인 아웃라인을 그리는 방법이 나을 수 있습니다. 이런 경우, 기획이 지속적으로 바뀌는 과정에서 초반에 테스트를 짜다가 이후에 다시 짜야 하거나 지워야 할 경우가 높기 때문에 시간 낭비라고 느껴질 수도 있습니다.
지금까지 살펴본 단점들을 요약한 가장 큰 단점이라고 하면 바로 속도입니다. 장기적으로 피할 수 있는 문제들을 피할 수 있다는 점에서 반론의 여부가 있을 수 있겠지만 속도가 느리다는 생각이 기본 정설입니다.
Popularity
위에 살펴본 단점들 때문에 완전한 TDD를 따르는 사람들은 적습니다. 그럼에도 자동화된 테스트를 작성하는 것은 기본이며, 어느정도 프로젝트가 완성되고 나면 테스트를 작성하게 됩니다. 탄탄한 프로그래밍 팀은 테스트를 포함하지 않은 코드에 대한 pull request 요청이 들어왔을 때, 정말 사소한 부분이 아니고서는 merge하지 않습니다.
Should I use it?
당연히 시도해봐야 합니다! 완벽하게 TDD를 짜려고 하면 골머리를 앓을 것입니다. 대부분의 사람처럼 코드를 작성하는 과정 중 "가까운 시일 내에" 작성하게 되더라도, 작성하려는 코드에 대해 특정한 규칙을 설정하고 고민하면서, 코드가 큰 틀에서 어떤 의미를 갖게 되는지 살피는 것은 분명 특별한 경험이 될 것입니다.
