테스트 주도 개발

TDD란 무엇인가

테스트 주도 개발(Test-Driven Development, TDD)은 구현보다 테스트를 먼저 작성하는 개발 방식이다. 아직 존재하지 않는 기능에 대해 실패하는 테스트를 먼저 기술하고, 그 테스트를 통과시키는 최소한의 코드를 작성하는 순서를 따른다.

테스트가 곧 명세의 역할을 하므로, 무엇을 만들어야 하는지를 코드로 먼저 못 박는 셈이다. 기능을 다 만든 뒤 검증을 붙이는 통상의 흐름을 뒤집어, 검증 기준을 설계의 출발점으로 끌어올린 것이 핵심이다.

레드·그린·리팩터

TDD는 세 단계의 짧은 순환을 반복한다. 먼저 실패하는 테스트를 써서 붉은 신호를 만들고(레드), 그 테스트만 통과하도록 가장 단순한 코드를 채워 초록 신호로 바꾼다(그린).

이어서 동작을 유지한 채 중복과 군더더기를 정리하는 리팩토링 단계를 거친다. 한 순환은 길지 않으며, 작은 보폭으로 자주 도는 것이 권장된다.

각 단계의 경계가 분명하기 때문에 지금 무엇에 집중해야 하는지가 항상 명확하다. 통과시키는 데 급급해 설계 정리를 건너뛰면 코드가 빠르게 지저분해지므로, 세 단계를 빠짐없이 도는 규율이 효과의 전제가 된다.

테스트가 설계를 끌어낸다

TDD가 단순한 검증 기법과 구별되는 지점은 설계에 미치는 영향에 있다. 테스트를 먼저 쓰려면 그 기능을 어떻게 호출하고 어떤 결과를 기대할지 미리 정해야 하므로, 자연스럽게 호출 측 관점에서 인터페이스를 다듬게 된다.

테스트하기 어려운 구조는 대개 결합도가 높거나 책임이 뒤섞인 신호이며, 이를 풀어내는 과정에서 설계가 개선된다. 즉 테스트는 결과를 확인하는 도구를 넘어, 더 나은 구조를 끌어내는 압력으로 작동한다.

단위 테스트와의 관계

TDD의 순환은 주로 단위 테스트를 매개로 돌아간다. 작은 단위의 동작을 빠르게 검증할 수 있어야 짧은 순환이 성립하기 때문이다.

다만 TDD가 곧 단위 테스트와 같은 말은 아니다. 단위 테스트는 검증의 범위를 가리키는 개념이고, TDD는 그 테스트를 언제 작성하느냐는 순서에 관한 규율이다.

따라서 같은 단위 테스트라도 구현 이후에 붙이면 검증에 그치지만, 구현 이전에 쓰면 설계를 이끄는 도구가 된다. 이 순서의 차이가 같은 결과물에서도 전혀 다른 효과를 만들어 낸다.

리팩토링을 떠받치는 안전망

TDD가 누적해 온 테스트는 이후 변경의 안전망이 된다. 코드를 정리하거나 구조를 바꿀 때, 충분한 테스트가 있으면 동작이 깨졌는지를 즉시 확인할 수 있어 과감한 개선이 가능해진다.

안전망이 없으면 리팩토링은 위험 부담이 큰 작업이 되고, 결국 손대기 두려운 코드로 굳어진다. 반대로 테스트가 촘촘하면 변경의 비용이 낮아져 코드가 오래 건강하게 유지된다.

이 점에서 TDD의 산출물은 기능 코드와 테스트라는 두 자산이다.

오해와 적용의 균형

TDD를 모든 코드에 기계적으로 적용해야 한다는 인식은 흔한 오해다. 규칙이 단순한 화면 연결이나 외부 의존이 큰 영역에서는 비용 대비 효과가 떨어질 수 있다.

반대로 비즈니스 규칙이 복잡하고 결함의 파급이 큰 핵심 로직에서는 효과가 두드러진다. 또한 테스트를 형식적으로 채워 통과시키는 데만 매달리면, 깨지기 쉽고 의미 없는 테스트가 쌓여 오히려 짐이 된다.

어디에 어느 깊이로 적용할지를 가늠하는 판단이 도구 자체보다 중요하다.