테스트 주도 개발 TDD(Test-driven Development)

TDD(Test-driven Development)는 코드를 작성하기 전에 테스트를 쓰는 방법론입니다.

 

Pros

대부분의 사람은 TDD를 버그 잡는 방법이라고 생각합니다. 그런 면도 있지만 생각해보면 버그를 잡기 위해 테스트를 짠다는 생각은 비직관적입니다. 테스트를 실행하고 그 후에 버그를 잡는다고 생각하는 것이 더 논리적일 것입니다.

실제로 TDD를 통해 정교한 테스트를 짜기 위해서 코드를 어떻게 구성할지 고민하게 되며, 그 과정에서 버그가 더 적은 코드를 짜게 됩니다. 테스트가 쉽도록 코드를 디자인하는 것도 같은 효과를 내게 됩니다.

TDD는 무턱대고 코드를 바로 작성하지 않고 코드를 면밀하게 살펴보도록 합니다. 자신이 작성할 코드가 어떤 역할을 하게 되며, 전체와 어떤 관계가 있는지 생각하게 합니다.

 

 

Cons

TDD는 프로그래머들이 자연스럽게 생각하고 일하는 방식과 일치하지 않습니다. 소프트웨어는 집을 건축하는 것과는 달리 더 유동적입니다. 아마 대부분의 프로그래머는 테스트를 작성하는 것보다 바로 뭔가 만들어내고 싶어 할 것입니다.

같은 맥락에서 또 살펴보면, 코드를 디자인한다는 것은 초반에 명확하지 않을 수 있고 대신 빠르게 프로토타입을 만들어 전반적인 아웃라인을 그리는 방법이 나을 수 있습니다. 이런 경우, 디자인이 지속적으로 바뀌는 과정에서 초반에 테스트를 짜다가 이후에 다시 짜야 하거나 지워야 할 경우가 높기 때문에 시간 낭비라고 느껴질 수도 있습니다.

지금까지 살펴본 단점들을 요약한 가장 큰 단점이라고 하면 바로 속도입니다. 장기적으로 피할 수 있는 문제들을 피할 수 있다는 점에서 반론의 여부가 있을 수 있겠지만 속도가 느리다는 생각이 기본 정설입니다.

 

Popularity

위에 살펴본 단점들 때문에 완전한 TDD를 따르는 사람들은 적습니다. 그럼에도 자동화된 테스트를 작성하는 것은 기본이며, 코드를 작성하는 과정 중 가까운 시일 내에 작성하게 됩니다.

예를 들어, 탄탄한 프로그래밍 팀은 테스트를 포함하지 않은 코드에 대한 pull request 요청이 들어왔을 때, 정말 사소한 부분이 아니고서는 merge하지 않습니다.

 

Should I use it?

당연히 시도해봐야 합니다! 완벽하게 TDD를 짜려고 하면 골머리를 앓을 것입니다. 대부분의 사람처럼 코드를 작성하는 과정 중 "가까운 시일 내에" 작성하게 되더라도, 작성하려는 코드에 대해 특정한 규칙을 설정하고 차근차근 생각함으로, 코드가 큰 틀에서 어떤 의미를 갖게 되는지 살피는 것은 분명 특별한 경험이 될 것입니다.