TDD(테스트 주도 개발 방법론) 알아보기

김내현·2025년 2월 12일

개인공부

목록 보기

47/51

TDD(Test Driven Development) 란?

테스트 주도 개발
반복 테스트를 이용한 소프트웨어 방법론으로,작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다.
짧은 개발 주기의 반복에 의존하는 개발 프로세스이며, 애자일 방법론 중 하나인eXtream Programming(XP)의 'Test-First' 개념에 기반을 둔 단순한 설계를 중요시한다.

💡

TipeXtream Programming(XP)미래에 대한 예측을 최대한 하지 않고, 지속적으로 프로토타입을 완성하는 애자일 방법론이다. 이 방법론은 추가 요구사항이 생기더라도, 실시간으로 반영할 수 있다.

호불호가 갈리는 TDD

TDD의 실효성을 업무로 경험한 사람들은 TDD를 더 효과적으로 실무에 적용하기 위해 고민한다.반면, 회사마다 일하는 방식이나 처한 업무 환경에 편차가 있다보니 일각에서는 실무에서 TDD를 사용하는 건 사실상 현실과 괴리감이 크다는 의견도 있다.

TDD 개발주기

!https://blog.kakaocdn.net/dn/bRsHuS/btrraBsKjY8/sESZMUlX7GRvtTkYpKYx30/img.png

1. Red단계에서는 실패하는 테스트 코드를 먼저 작성한다.

2. Green단계에서는 테스트 코드를 성공시키기 위한 실제 코드를 작성한다.

3. Blue단계에서는 중복 코드 제거, 일반화 등의 리팩토링을 수행한다.

중요한 것은 실패하는 테스트 코드를 작성할 때 까지 실제 코드를 작성하지 않는 것, 그리고 실패하는 테스트를 통과할 정도의 최소 실제 코드를 작성해야 하는 것이다. 이를 통해, 실제 코드에 대해 기대되는 바를 보다 명확하게 정의함으로써 불필요한 설계를 피할 수 있고, 정확한 요구 사항에 집중할 수 있다.

!https://blog.kakaocdn.net/dn/11xgM/btrrcomz2oH/LYRaOVrLkFBCk4wZIKoTa1/img.png

TDD를 적용한 사례 :

TDD 개발 주기를 적용한 시나리오: To-Do List 앱의 "할 일 추가" 기능

1단계: 요구사항 분석

입력 필드에 텍스트를 입력한다.
"ADD" 버튼을 클릭한다.
텍스트가 할 일 목록에 추가된다.

2단계: 테스트 작성 (Red)

목표: 요구사항을 검증하는 테스트를 작성한다.
테스트를 통해 입력 필드, 버튼, 그리고 할 일 목록이 올바르게 동작하는지 확인한다.
현재 기능이 구현되지 않았으므로 테스트는 실패한다.

3단계: 최소 기능 구현 (Green)

목표: 테스트를 통과할 수 있도록 최소한의 코드를 작성한다.
입력 필드에서 텍스트를 읽고, 버튼을 클릭하면 목록에 추가하는 동작을 구현한다.
테스트를 실행하면 성공한다.

4단계: 리팩토링 (Refactor)

목표: 작성한 코드를 개선하여 가독성과 유지보수성을 높인다.
컴포넌트를 분리하거나 상태 관리 방식을 개선한다.
리팩토링 후에도 모든 테스트가 성공해야 한다.

5단계: 기능 확장

목표: 추가 요구사항을 정의하고, 동일한 TDD 주기를 반복한다.
예를 들어, 다음 기능들을 구현:
1. 할 일 삭제: 목록에서 특정 항목을 제거할 수 있다.
2. 완료 표시: 완료된 할 일을 구분할 수 있다.
3. 데이터 저장: 목록을 로컬 스토리지에 저장하고, 페이지를 새로 고쳐도 유지된다.

결과

TDD 주기를 통해 할 일 추가 기능을 안정적으로 구현하고, 코드 품질을 유지하면서 점진적으로 기능을 확장할 수 있다.

일반 개발 방식 vs TDD 개발 방식

➡️ 일반적인 개발

!https://blog.kakaocdn.net/dn/cdoNDm/btrq5oIwUb2/fUJIAjwbfOe3EwBvnxANz1/img.png

보통의 개발 방식은'요구사항 분석 -> 설계 -> 개발 -> 테스트 -> 배포'의 형태의 개발 주기를 갖는데 이러한 방식은 소프트웨어 개발을 느리게 하는 잠재적 위험이 존재한다.

그 이유로는,

소비자의 요구사항이 처음부터 명확하지 않을 수 있다.
따라서 처음부터 완벽한 설계는 어렵다.
자체 버그 검출 능력 저하 또는 소스코드의 품질이 저하될 수 있다.
자체 테스트 비용이 증가할 수 있다.

이러한 문제점들이 발생되는 이유는 어느 프로젝트든 초기 설계가 완벽하다고 말할 수 없기 때문이다.

보통 고객의 요구사항 또는 디자인의 오류 등 많은 외부 또는 내부 조건에 의해,재설계하여 점진적으로 완벽한 설계로 나아간다.

하지만 재설계로 인해 개발자는 코드를 삽입, 수정, 삭제 하는 과정에서 불필요한 코드가 남거나 중복처리 될 가능성이 크다.

결론적으로 이러한 코드들은 재사용이 어렵고 관리가 어려워져 유지보수를 어렵게 만든다.

작은 부분의 기능 수정에도 모든 부분을 테스트해야 하므로 전체적인 버그를 검출하기 어려워진다.

따라서 자체 버그 검출 능력이 저하된다. 그 결과 어디서 버그가 발생할지 모르기 때문에 잘못된 코드도 고치지 않으려 하는 현상이 나타나고 이 현상은 소스코드의 품질 저하과 직결된다.

이렇게 작은 수정에도 모든 기능을 다시 테스트해야 하는 문제가 발생하여 자체 테스트 비용이 증가된다.

🔄 TDD 개발

!https://blog.kakaocdn.net/dn/lVDC8/btrq6PyRiWV/9ee7BoHYKgftKkRg3RH0bk/img.png

TDD와 일반적인 개발 방식의 가장 큰 차이점은 테스트 코드를 작성한 뒤에 실제 코드를 작성한다는 점이다.

디자인(설계) 단계에서 프로그래밍 목적을 반드시 미리 정의해야만 하고,

또 무엇을 테스트해야 할 지. 미리 정의(테스트 케이스 작성)해야만 한다.

테스트 코드를 작성하는 도중에 발생하는 예외 사항(버그, 수정사항)들은 테스트 케이스에 추가
이후 테스트가 통과된 코드만을 코드 개발 단계에서 실제 코드로 작성

💡

이러한 반복적인 단계가 진행되면서 자연스럽게 코드의 버그가 줄어들고, 소스코드는 간결해진다.

또한, 테스트 케이스 작성으로 인해 자연스럽게 설계가 개선됨으로 재설계 시간이 절감된다.

TDD의 효과

디버깅 시간 단축

TDD는 자동화된 유닛 테스트를 기반으로 하기 때문에, 문제 발생 시 어느 레이어(UI, 비즈니스 로직, 데이터베이스)에서 오류가 발생했는지 빠르게 파악할 수 있다.
빠른 피드백

TDD는 기능 단위로 테스트를 진행하므로, 코드를 모두 완성하기 전에 피드백을 받을 수 있다. 이를 통해 문제를 조기에 발견하고 수정할 수 있다.
코드 장악력 확보

코드가 사용자에게 전달되기 전에 테스트를 통해 안정성을 확인할 수 있으므로, 코드의 불확실성과 불안정성을 지속적으로 해소할 수 있다.
재설계 시간 단축

테스트 코드를 먼저 작성하면서 예외 상황까지 고려하기 때문에, 소프트웨어 설계 변경을 줄이고 개발 방향을 명확히 할 수 있다.
추가 구현 용이

자동화된 테스트가 기존 코드에 새로운 기능이 미치는 영향을 빠르게 파악하도록 도와준다. 이는 테스트 기간을 줄이고 기능 추가 시 안심할 수 있게 한다.

TDD의 단점

생산성 저하

초기에 테스트 코드를 포함한 두 배의 코드를 작성해야 하며, 테스트와 수정 과정을 반복해야 하기 때문에 개발 시간이 10~30% 늘어날 수 있다. 특히, 품질보다 속도가 중요한 SI 프로젝트에서는 적용이 어렵다.
낯선 개발 방식

기존 방식에 익숙한 개발자들에게 TDD는 익숙하지 않아 받아들이기 어려울 수 있다. 반면, 경험이 적은 개발자들에게는 상대적으로 적응이 쉬운 편이다.
구조에 얽매임

예외적인 상황에서 테스트 원칙과 실제 코드 구현 사이의 갈등이 발생할 수 있다. 테스트 원칙을 지키려다 보면 과도한 구조 변경이나 비효율적인 코드가 작성될 가능성도 있다.

Jest

💡

Jest는 JavaScript와 TypeScript 애플리케이션을 위한 테스트 프레임워크이다. Facebook에서 개발하였으며, React 프로젝트에서 사용하기 적합하지만 그 외의 JavaScript 프로젝트에서도 사용할 수 있다. Jest는 단위 테스트(Unit Test), 통합 테스트(Integration Test), 엔드투엔드 테스트(End-to-End Test)를 지원하며, 사용하기 쉽고 강력한 기능을 제공한다.

간단한 설정: 기본적으로 설정 파일 없이도 실행 가능하다.
스냅샷 테스트: 컴포넌트의 렌더링 결과를 손쉽게 비교할 수 있다.
빠른 실행: 병렬 실행 및 파일 변경 감지를 통해 테스트 속도가 빠르다.
Mocking 지원: 함수, 모듈, 타이머 등을 쉽게 Mock 처리할 수 있다.

Jest 설치 방법

Jest를 설치하려면 npm이나 Yarn을 사용하면 된다.

npm install --save-dev jest

설치 후 package.json의 scripts에 Jest 실행 명령어를 추가할 수 있다.

{
  "scripts": {
    "test": "jest"
  }
}

이제 npm test 명령어로 Jest 테스트를 실행할 수 있다.

https://www.youtube.com/watch?v=g4MdUjxA-S4&list=PLZKTXPmaJk8L1xCg_1cRjL5huINlP2JKt

간단 실습

RBF 후기

세빈: 애자일하다는 밈을 어디서 본 적이 있는데 이게 이런 뜻이었군요! 수고하셨습니다!

내현: 불을 처음 발견한 원시인 느낌이었습니다. 몰랐던 내용을 새로 알게 되어 좋았습니다.

예빈: 실제 개발 환경에 대해 알 수 있어서 좋았다. 1차 프로젝트 때 어떻게 개발을 했었지 대입을 해보면서 들었다.

승현: 수업내용 외의 것은 잘몰랐었는데, TDD 나중에 한 번 공부해서 사용해보싶습니다!

민혁: 아주 간단한 mock api를 만들때는 json-server 를 사용할 수도 있으니 참고하세용

보아: 정처기에서 이론적으로만 알았던 내용인데, 자세하게 다뤄주셔서 감사합니당

김내현

이전 포스트

typeScript interface, Generic (+terminal 조금)

다음 포스트