[개발 방법론] TDD (Test-Driven Development)

소프트웨어 개발 개념 정리

CodeWithBeam 2025. 2. 9. 23:20

(소프트웨어 개발에서 모든 코드는 오류없이 정상 작동하는지 확인하기 위해 테스트를 거치게 되는데 TDD의 경우는 제품의 기능 구현 코드와는 별개로 해당 기능이 정상적으로 작동하는지 검증하기 위한 테스트 코드를 먼저 작성한다.

이후 테스트가 실패할 경우, 테스트를 통과하기 위해 기능을 구현하고 기능 구현이 성공하면 최종적으로 리팩토링거쳐 코드의 품질을 개선하는 절차를 거친다.

이러한 과정이 반복적으로 이루어져 코드 구현이 완성된다.)

TDD는 아래의 3단계의 순환 과정을 반복하며 진행된다.

1단계: RED ➡️ 실패하는 테스트 코드 작성

(실패하는 것이 확인되어야 테스트가 검증력을 가진다. 실패의 이유는 기능이 아직 없기 때문이다.

따라서 실패하는 이유가 테스트 코드의 문제이면 안 된다.)

2단계: GREEN ➡️ 테스트 코드를 통과시킬 최소한의 코드 작성

(테스트의 성공은 모든 요구사항을 만족했음을 의미한다.)

3단계: REFACTOR ➡️ 코드 리팩토링

(리팩토링 후에도 모든 테스트가 통과되어야 한다. 그래야 기존 기능이 잘 유지 되고 있음을 알 수 있다.)

🌟Keypoint 🌟

실패하는 테스트 코드를 작성하기 전까지는 실제 코드를 작성하지 않아야 한다.

테스트가 실패한 후, 테스트가 통과할 최소한의 실제 코드만 작성하는 것이 핵심이다.

이 접근법을 통해 실제 코드가 수행해야 할 기대 사항을 명확하게 정의할 수 있으며, 불필요한 설계를 방지하고 정확한 요구 사항에 집중할 수 있다.

코드 품질 향상: 테스트를 기반으로 하기 때문에 버그 발생이 줄어든다.
리팩토링이 용이: 기능이 잘 동작 하는지 항상 검증 가능하다.
유지보수성 증가: 새로운 기능 추가 시, 기존 기능이 깨지는 문제를 방지할 수 있다.
요구사항 명확화: TDD를 통해 작성한 테스트 코드를 트래킹하면서 과거에 어떤 인과관계로 의사결정을 했는지 확인하기 쉽기 때문에 요구사항을 깊이 이해할 수 있다.

초기 개발 속도가 느림: 단순한 기능조차도 테스트 코드를 먼저 작성해야 하므로 초기 개발 속도가 느려질 수 있다.
복잡한 로직에서는 테스트 코드 작성 어려움: 비즈니스 로직이 복잡할 경우 테스트 코드 작성이 어렵거나 비효율 적일 수 있다. 예: 웹소켓을 이용한 실시간 채팅 서비스의 연결 테스트는, 네트워크 환경에 따라 테스트 결과가 달라질 수 있어 어렵다.
TDD경험이 부족한 개발자는 오히려 생산성이 감소: 테스트코드 작성에 집중하다가 실제 코드 구현이 늦어질 수 있다.

참고: "TDD란? 테스트주도개발에 대한 편견과 실상, 방법론" - Fast campus (https://media.fastcampus.co.kr/knowledge/dev/tdd/)