TDD (r1)

TDD의 핵심 실천법은 Red-Green-Refactor 사이클이라는 반복적인 흐름이다. 이 사이클은 매우 짧은 주기로 반복되며, 각 단계는 명확한 목표와 산출물을 가진다. 개발자는 이 세 단계를 통해 점진적으로 기능을 완성하고 코드 품질을 높인다.

첫 번째 단계인 Red는 실패하는 테스트를 작성하는 단계이다. 개발자는 구현하려는 기능의 작은 단위에 대한 테스트 코드를 먼저 작성한다. 이때 테스트는 당연히 실패해야 하며, 이는 구현 코드가 아직 존재하지 않거나 요구사항을 만족하지 못하기 때문이다. 실패하는 테스트를 확인하는 것은 테스트가 올바르게 동작한다는 신뢰를 준다.

두 번째 단계인 Green은 최소한의 코드만을 작성하여 테스트를 통과시키는 단계이다. 이 단계의 목표는 설계의 우아함이나 코드의 완벽함이 아닌, 단순히 테스트를 성공시키는 것이다. 때로는 하드 코딩된 값을 반환하는 등의 간단한 방법을 사용하기도 한다. 테스트가 통과하면 요구된 기능이 기본적으로 동작한다는 것을 보장받게 된다.

세 번째 단계인 Refactor는 통과된 테스트를 바탕으로 코드를 개선하는 단계이다. Green 단계에서 작성된 최소한의 코드는 중복, 나쁜 냄새, 비효율적인 구조를 가질 수 있다. 개발자는 이 단계에서 리팩토링을 수행하여 코드의 가독성, 유지보수성, 설계를 개선한다. 테스트가 계속 통과하는지 확인하면서 안전하게 코드 구조를 변경할 수 있다. 이 사이클이 완료되면, 다음 작은 기능에 대해 새로운 Red 단계부터 다시 시작한다.

테스트 우선 개발은 TDD의 핵심 원칙으로, 실제 기능 코드를 작성하기 전에 해당 기능의 실패하는 테스트 코드를 먼저 작성하는 접근법이다. 이는 개발 과정에서 테스트의 역할을 단순한 검증 도구가 아닌 설계 도구로 전환시킨다. 개발자는 구현해야 할 기능의 명세를 테스트 코드의 형태로 구체화함으로써, 무엇을 만들어야 하는지에 대한 명확한 목표를 설정하게 된다.

테스트 우선 개발의 일반적인 절차는 다음과 같다. 먼저, 추가하려는 작은 기능 하나에 대해 실패할 것으로 예상되는 테스트를 작성한다. 이때 테스트는 기능의 인터페이스(메서드명, 매개변수, 예상 결과)를 정의하는 역할을 한다. 그다음, 최소한의 코드만을 작성하여 방금 만든 테스트를 통과시킨다. 마지막으로, 통과된 코드를 개선하며 리팩토링을 수행한다. 이 세 단계(실패-성공-개선)의 반복이 곧 Red-Green-Refactor 사이클을 구성한다.

이 접근법의 주요 이점은 설계에 대한 피드백을 즉시 얻을 수 있다는 점이다. 테스트하기 쉬운 코드는 일반적으로 결합도가 낮고 응집도가 높은 모듈화된 구조를 가지기 마련이다. 테스트를 먼저 작성하면 자연스럽게 사용자 관점에서의 인터페이스와 의존성 관리에 대해 고민하게 되어, 더 깔끔한 API 설계로 이어지는 경우가 많다. 또한, 테스트 스위트가 자동화된 문서 역할을 하여, 코드의 의도와 사용법을 명확히 전달한다.

테스트 우선 개발을 성공적으로 적용하기 위해서는 작은 단위로 기능을 분해하고 점진적으로 접근하는 것이 중요하다. 한 번에 너무 많은 기능을 테스트하려고 하면 테스트 자체가 복잡해지고 사이클이 무너질 수 있다. 따라서 기능을 가능한 한 작은 단위로 쪼개고, 각 단위에 대해 독립적인 테스트를 작성하며 진행하는 것이 바람직하다.

TDD를 통해 작성된 코드는 일반적으로 더 높은 신뢰성과 유지보수성을 가집니다. 이는 개발 과정 자체가 지속적인 검증을 통해 이루어지기 때문입니다. 모든 기능은 실패하는 테스트를 먼저 작성한 후, 그 테스트를 통과할 만큼의 최소한의 코드만 작성하여 구현됩니다. 이 과정은 코드가 명세대로 정확히 동작한다는 것을 보장하는 안전망 역할을 합니다. 또한, 테스트 스위트가 구축됨에 따라 회귀 테스트가 자동화되어, 새로운 기능 추가나 기존 코드 수정 시 의도치 않게 발생하는 버그를 빠르게 발견할 수 있습니다.

코드 품질 향상은 테스트 가능한 설계를 강제한다는 점에서도 나타납니다. TDD는 테스트하기 쉬운 코드를 작성하도록 유도하며, 이는 자연스럽게 결합도가 낮고 응집력이 높은 모듈화된 설계로 이어집니다. 예를 들어, 외부 의존성이 강한 코드는 테스트하기 어려우므로, 개발자는 의존성 주입이나 인터페이스 분리 원칙과 같은 설계 기법을 적용하여 테스트 가능한 구조로 리팩토링하게 됩니다. 결과적으로 코드의 각 구성 요소는 명확한 책임을 지니고, 다른 부분과 느슨하게 연결됩니다.

다음 표는 TDD가 코드 품질에 미치는 주요 영향을 정리한 것입니다.

궁극적으로, TDD는 단순한 테스트 작성 기법을 넘어 소프트웨어의 품질을 내재시키는 개발 철학에 가깝습니다. 테스트 가능성과 명확성을 우선시하는 이 접근법은 장기적으로 코드베이스의 복잡성을 관리하고 기술 부채의 증가를 억제하는 데 기여합니다.

TDD는 테스트를 먼저 작성함으로써 코드의 설계에 대한 고민을 앞당기게 한다. 개발자는 기능을 구현하기 전에 해당 기능의 인터페이스와 사용법을 테스트 코드로 정의해야 한다. 이 과정에서 불필요한 복잡성이나 모호한 인터페이스가 드러나며, 사용자 중심의 간결한 API 설계를 유도받게 된다.

테스트 가능한 코드는 일반적으로 결합도가 낮고 응집도가 높은 모듈식 설계를 갖추는 경향이 있다. 테스트를 먼저 작성하면 의존성을 주입받기 쉬운 구조가 자연스럽게 만들어지며, 이는 단일 책임 원칙을 준수하는 작은 클래스와 메서드로 이어진다. 결과적으로 시스템의 각 구성 요소가 명확한 책임을 지니고 다른 부분과 느슨하게 연결된 설계가 도출된다.

다음은 TDD가 설계에 미치는 긍정적 영향을 요약한 표이다.

이러한 설계상의 이점은 단기적인 구현보다 장기적인 유지보수와 확장에 더 큰 가치를 부여한다. 테스트 스위트가 존재하기 때문에 설계를 개선하는 리팩토링을 안전하게 수행할 수 있어, 설계의 질을 시간이 지나도 유지하거나 향상시키는 데 기여한다.

TDD의 핵심 사이클인 Red-Green-Refactor에서 리팩토링은 필수적인 단계이다. 기능 구현을 위한 테스트를 통과시키는 것만이 목표가 아니라, 그 과정에서 생긴 코드의 중복이나 나쁜 냄새를 지속적으로 제거하여 깨끗한 코드를 유지하는 것이 중요하다. TDD는 이러한 리팩토링을 안전하게 수행할 수 있는 안전망을 제공한다. 이미 통과한 테스트 케이스들이 존재하기 때문에, 개발자는 코드 구조를 변경하면서도 기존 기능이 정상적으로 동작하는지 즉시 확인할 수 있다.

리팩토링 단계에서는 성능 최적화보다는 가독성 향상, 중복 제거, 응집도 높이기, 결합도 낮추기 등 설계 개선에 초점을 맞춘다. 예를 들어, 긴 메서드를 작은 메서드로 분리하거나, 비슷한 코드를 공통 모듈로 추출하는 작업을 수행한다. TDD를 통해 자주 그리고 소규모로 리팩토링을 진행하면, 코드베이스가 복잡해질수록 발생하는 기술 부채의 누적을 효과적으로 방지할 수 있다.

이러한 접근 방식은 코드 변경에 대한 두려움을 줄여준다. 테스트 스위트가 충분히 커버리지를 제공한다면, 개발자는 기존 코드를 마음껏 개선할 수 있는 자신감을 얻는다. 결과적으로 시스템의 유지보수성이 크게 향상되고, 새로운 기능 추가나 요구사항 변경에 더 민첩하게 대응할 수 있는 기반이 마련된다.

TDD를 효과적으로 적용하기 위해서는 새로운 사고방식과 기술 습득이 필요합니다. 이는 단순히 테스트를 작성하는 방법을 배우는 것을 넘어, 설계와 문제 해결 접근 방식 자체를 변화시키는 과정을 포함합니다.

초보 개발자에게 가장 큰 장벽은 "무엇을 테스트해야 하는가"에 대한 판단입니다. 단순한 Getter와 Setter 메서드에 대한 테스트를 작성하는 것부터 복잡한 비즈니스 로직의 경계 조건을 식별하는 것까지, 테스트의 범위와 수준을 결정하는 데 익숙해지는 데 시간이 걸립니다. 또한, 테스트 가능한 설계를 위해 의존성 주입이나 인터페이스 분리 원칙 같은 설계 원칙에 대한 이해가 선행되어야 하는 경우도 많습니다.

실무 환경에서 TDD를 도입할 때는 팀 차원의 학습 비용이 발생합니다. 모든 구성원이 일관된 테스트 작성 규칙과 표준을 공유해야 하며, 기존의 레거시 코드베이스에 TDD를 점진적으로 적용하는 방법에 대한 합의가 필요합니다. 이 과정에서 초기 생산성 저하가 불가피하며, 팀 내에 TDD의 가치에 대한 확신을 공유하지 못하면 실패로 이어질 수 있습니다[1]. 따라서 체계적인 교육, 멘토링, 그리고 작은 프로젝트부터의 점진적 적용이 학습 곡선을 완만하게 만드는 데 도움이 됩니다.

TDD를 처음 도입하는 팀이나 개발자는 기능 구현 자체보다 테스트 코드 작성에 더 많은 시간을 소모하게 되어 초기 개발 속도가 느려지는 현상을 경험한다. 이는 익숙하지 않은 테스트 케이스 설계, 테스트 프레임워크 학습, 그리고 테스트 가능한 코드를 고민하는 과정에서 발생하는 자연스러운 결과이다.

특히 복잡한 도메인 로직이나 외부 시스템과의 연동이 필요한 경우, 테스트를 위한 모의 객체 설정과 의존성 주입 구조를 만드는 작업이 추가 부담으로 작용한다. 단순히 기능을 빠르게 구현하는 것보다 테스트를 먼저 통과시키는 방식에 적응하는 데 시간이 필요하다.

하지만 이는 일시적인 현상으로, TDD 사이클에 익숙해지고 테스트 스위트가 축적되면 오히려 개발 속도가 안정화되고 향상되는 경우가 많다. 장기적으로는 리팩토링 시간 단축과 디버깅 부담 감소로 인해 전체적인 생산성이 높아진다는 연구 결과도 존재한다[2]. 따라서 초기 속도 저하는 TDD 학습 과정의 투자 비용으로 간주된다.

테스트 케이스는 TDD 사이클의 시작점이자 명세 역할을 한다. 따라서 명확하고 검증 가능한 단일 책임을 가져야 한다. 하나의 테스트는 하나의 시나리오나 조건만을 검증하는 것이 좋다. 테스트 메서드명은 테스트 대상 메서드명과 예상 동작, 조건을 포함하여 의도를 명확히 드러내는 것이 일반적이다. 예를 들어, '입금_후_잔액이_증가한다' 또는 '잔액부족시_출금_실패한다'와 같은 형식을 사용한다.

좋은 테스트 케이스는 FIRST 원칙을 따르는 것으로 평가된다. 이 원칙은 테스트가 Fast(빠르게), Independent(독립적으로), Repeatable(반복 가능하게), Self-Validating(스스로 검증 가능하게), Timely(적시에 작성되어야 함) 해야 함을 의미한다. 특히 독립성은 각 테스트가 다른 테스트의 결과에 영향을 받지 않고 어떤 순서로 실행되어도 동일한 결과를 내야 함을 보장한다.

테스트 케이스의 구조는 일반적으로 Given-When-Then 패턴을 따른다. 이는 테스트를 준비, 실행, 검증의 세 단계로 명확히 구분한다. Given 단계에서는 테스트에 필요한 객체 상태와 데이터를 설정한다. When 단계에서는 테스트 대상 메서드나 기능을 실행한다. Then 단계에서는 실행 결과가 기대하는 조건을 만족하는지 단언문을 통해 검증한다. 이 패턴은 테스트의 가독성과 유지보수성을 크게 높인다.

테스트는 가능한 한 구체적인 실패 메시지를 제공하도록 작성해야 한다. 이를 위해 단언문의 메시지 파라미터를 활용하거나, 적절한 매처를 사용한다. 또한 경계 조건(예: null 입력, 빈 문자열, 최대값/최소값)에 대한 테스트를 포함하는 것이 중요하다. 이는 예상치 못한 오류를 사전에 발견하는 데 도움이 된다.

TDD 과정에서 테스트 대상 코드가 의존하는 외부 모듈(예: 데이터베이스, 네트워크 서비스, 복잡한 라이브러리)은 실제로 사용하기 어렵거나 느린 경우가 많다. 이때 모의 객체는 이러한 의존성을 격리하고 제어하기 위한 도구로 활용된다. 모의 객체는 실제 객체의 인터페이스를 시뮬레이션하지만, 사전에 정의된 특정 동작만을 수행하도록 프로그래밍할 수 있다.

모의 객체를 활용하는 주요 목적은 테스트의 단위를 명확히 하고 실행 속도를 높이며, 외부 조건에 의존하지 않는 견고한 테스트를 작성하는 데 있다. 예를 들어, 사용자 정보를 데이터베이스에서 조회하는 메서드를 테스트할 때, 실제 데이터베이스에 연결하는 대신 모의 객체를 사용해 특정 ID에 대해 미리 정의된 가짜 사용자 객체를 반환하도록 설정할 수 있다. 이를 통해 네트워크 지연이나 데이터베이스 상태와 무관하게 항상 동일한 조건에서 로직만을 검증할 수 있다. 또한, 메서드가 특정 인자로 호출되었는지, 몇 번 호출되었는지 등의 상호작용을 검증하는 데에도 유용하게 사용된다.

모의 객체 사용 시 주의할 점은 과도한 사용이 테스트의 의미를 퇴색시킬 수 있다는 것이다. 모든 의존성을 모킹하면 실제 통합 환경에서의 동작을 보장하지 못할 수 있다. 따라서 단위 테스트의 핵심 로직 검증에는 모의 객체를 사용하되, 중요한 통합 흐름은 실제 객체를 사용하는 통합 테스트로 보완하는 것이 바람직하다. 일반적으로 불안정하거나 느린 외부 시스템(API, 파일 시스템, 랜덤 값 생성기 등)에 대한 의존성을 대체할 때 그 효과가 가장 크다.

주요 모의 객체 라이브러리로는 Java의 Mockito, Python의 unittest.mock, JavaScript의 Jest 내장 모킹 기능 등이 널리 사용된다. 이러한 도구들은 객체 생성, 메서드 호출 및 반환값 설정, 호출 검증 등을 편리하게 지원한다.

ATDD는 TDD의 확장된 개념으로, 개발 시작 전에 고객이나 비즈니스 이해관계자와 협력하여 인수 테스트를 먼저 정의하는 개발 방법론이다. 핵심 목표는 '어떤 기능이 완료되었다고 판단할 수 있는 기준'을 모든 이해관계자가 합의하는 것이다. 이는 단위 수준의 TDD가 개발자의 관점에서 코드 정확성을 검증하는 반면, ATDD는 사용자나 고객의 관점에서 시스템의 전체적인 동작과 가치 제공을 검증하는 데 중점을 둔다.

ATDD의 일반적인 프로세스는 협의, 명세화, 자동화의 세 단계로 이루어진다. 먼저 개발자, 테스터, 비즈니스 분석가, 고객 대표 등이 모여 사용자 스토리나 기능 요구사항을 논의하고, 해당 기능의 성공 기준을 예시를 통해 구체화한다. 이렇게 도출된 예시들은 'Given-When-Then' 형식과 같은 구조화된 문법으로 인수 테스트 케이스로 작성된다[3]. 이후 이 테스트 케이스들은 Cucumber, SpecFlow, Robot Framework 등의 도구를 이용해 실행 가능한 자동화 테스트 스크립트로 변환된다.

ATDD를 적용하면 요구사항에 대한 공통 이해를 형성하고 모호함을 줄일 수 있어, 개발이 끝난 후에 요구사항 오해로 인한 재작업을 방지하는 데 도움이 된다. 또한 자동화된 인수 테스트는 시스템의 핵심 비즈니스 가치가 항상 유지되도록 하는 살아있는 문서 역할을 하며, 회귀 테스트의 기반을 제공한다. 이 방법론은 애자일 또는 BDD 개발 환경과 자연스럽게 결합되어 사용된다.

BDD는 TDD의 한 갈래로, 테스트보다는 행위(Behavior)와 명세(Specification)에 초점을 맞춘 개발 방법론이다. 댄 노스가 2003년에 제안한 이 접근법은 기술 중심의 테스트 용어(예: test, assert) 대신 비즈니스 이해관계자와 개발자 모두가 이해할 수 있는 도메인 중심의 어휘(예: should, given-when-then)를 사용하여 시스템의 행위를 정의하는 것을 핵심으로 삼는다. BDD의 목표는 소프트웨어가 어떻게 동작해야 하는지에 대한 공통의 이해를 바탕으로, 올바른 소프트웨어를 구축하는 데 있다.

BDD는 일반적으로 사용자 스토리 형식을 기반으로 한 외부 명세(Feature 파일)와 내부 명세(단위 테스트 수준)의 두 층위로 실천된다. 외부 명세는 Given-When-Then 구조를 사용하여 기능의 수용 조건을 자연어에 가깝게 작성한다. 예를 들어, "Given 사용자가 로그인되어 있을 때, When 새 게시글을 작성하면, Then 게시판 목록에 글이 표시되어야 한다"와 같은 형식이다. 이 명세는 큐컴버나 스펙플로우와 같은 도구를 통해 실행 가능한 테스트로 변환된다. 내부 명세는 클래스나 함수 수준에서 시스템의 세부 행위를 기술하며, JBehave나 RSpec 같은 프레임워크를 활용하여 "시스템은 ~해야 한다"는 형식으로 작성된다.

BDD와 TDD의 주요 차이점은 초점과 언어에 있다. 다음 표는 두 방법론을 간략히 비교한다.

BDD를 실천함으로써 팀은 요구사항의 모호함을 줄이고, 문서로서 기능하는 살아있는 명세를 생성하며, 비기능적 요구사항(예: 성능, 보안)보다는 사용자 가치를 제공하는 기능적 행위에 집중할 수 있다. 이는 궁극적으로 사용자 중심의 소프트웨어 설계와 더 나은 커뮤니케이션을 촉진한다.

JUnit은 자바 프로그래밍 언어를 위한 사실상 표준 단위 테스트 프레임워크이다. 켄트 벡과 에리히 감마가 익스트림 프로그래밍의 일환으로 개발했으며, TDD 실천에 핵심적인 도구로 자리 잡았다. JUnit은 테스트 작성, 실행, 결과 확인을 위한 간결한 어노테이션 기반의 API를 제공하여 개발자가 빠르게 반복적인 테스트 주기를 수행할 수 있게 돕는다.

주요 어노테이션으로는 @Test(테스트 메서드 표시), @BeforeEach/@AfterEach(각 테스트 실행 전/후 작업), @BeforeAll/@AfterAll(전체 테스트 클래스 실행 전/후 작업) 등이 있다. 테스트 검증은 Assertions 클래스의 정적 메서드(예: assertEquals, assertTrue, assertThrows)를 통해 이루어진다. JUnit 5는 모듈식 아키텍처로 구성되어, 주로 JUnit Platform(테스트 실행 엔진), JUnit Jupiter(새로운 프로그래밍 모델 및 확장 모델), JUnit Vintage(JUnit 3/4 기반 테스트 실행 지원)라는 세 개의 하위 프로젝트로 나뉜다.

대부분의 현대 통합 개발 환경과 빌드 도구는 JUnit과의 원활한 통합을 지원한다. 인텔리제이, 이클립스, 메이븐, 그레이들 등에서 테스트 실행 및 리포트 생성을 자동화할 수 있어, 지속적 통합 파이프라인에 TDD를 적용하는 데 필수적이다. JUnit의 성공은 xUnit 패밀리라는 다양한 프로그래밍 언어용 단위 테스트 프레임워크 생태계를 탄생시키는 계기가 되었다.

pytest는 Python 프로그래밍 언어를 위한 테스트 프레임워크이다. 기존의 unittest 모듈에 비해 간결한 문법과 강력한 기능을 제공하여 TDD와 단위 테스트를 보다 효율적으로 수행할 수 있게 한다. assert 문을 기본으로 사용하기 때문에 별도의 테스트용 API를 학습할 필요가 적다는 특징이 있다.

pytest의 주요 기능으로는 픽스처를 통한 테스트 환경 설정, 매개변수화된 테스트 작성, 풍부한 플러그인 생태계를 들 수 있다. 픽스처는 @pytest.fixture 데코레이터로 정의하며, 데이터베이스 연결이나 임시 파일 생성과 같은 테스트 준비 및 정리 작업을 재사용 가능한 형태로 캡슐화한다. 매개변수화된 테스트는 @pytest.mark.parametrize 데코레이터를 사용하여 하나의 테스트 함수로 여러 입력값과 기대 결과를 검증할 수 있게 한다.

명령줄에서 실행할 때 유용한 여러 옵션을 제공한다. 예를 들어, -v 옵션은 상세한 출력을, -k 옵션은 이름에 특정 문자열이 포함된 테스트만 필터링하여 실행할 수 있다. 또한 테스트 커버리지를 측정하는 pytest-cov 플러그인과 같은 다양한 서드파티 플러그인과의 통합이 용이하다.

Jest는 페이스북에 의해 개발된 자바스크립트 및 타입스크립트를 위한 테스트 프레임워크이다. 주로 리액트와 같은 프론트엔드 라이브러리나 노드.js 기반 애플리케이션의 테스트에 널리 사용된다. 모든 기능이 내장된 '제로 컨피규레이션(zero-configuration)' 철학을 지향하여, 별도의 복잡한 설정 없이도 빠르게 테스트 환경을 구축하고 실행할 수 있다는 특징을 가진다.

Jest는 TDD 및 BDD 스타일의 테스트 작성을 모두 지원한다. 주요 기능으로는 강력한 모의 객체 기능, 코드 커버리지 리포트 자동 생성, 스냅샷 테스팅 등이 포함된다. 특히 리액트 컴포넌트의 UI를 안정적으로 검증하는 데 유용한 스냅샷 테스팅은 Jest의 대표적인 장점 중 하나이다.

다음은 Jest의 주요 특징을 정리한 표이다.

Jest는 describe, it(또는 test), expect와 같은 직관적인 글로벌 API를 제공하여 테스트 코드의 가독성을 높인다. 또한, 바벨, 웹팩, 타입스크립트 등 현대 자바스크립트 생태계의 도구들과의 원활한 통합을 지원한다. 이러한 이유로 Create React App과 같은 공식 보일러플레이트의 기본 테스트 러너로 채택되며, 자바스크립트 생태계에서 사실상의 표준 테스트 프레임워크로 자리 잡았다.