TDD

TDD

• 테스트 주도 개발(Test-Driven Development)의 약자
• 개발자가 코드를 작성하기 전에 테스트를 먼저 작성하는 소프트웨어 개발 방법론

 

 

TDD의 3단계 사이클

 

출처:https://sattlub123.medium.com

 

• RED
  • 실패하는 테스트를 작성
  • 아직 구현되지 않은 기능을 테스트로 정의
• GREEN
  • 테스트를 통과시키기 위해 최소한의 코드를 작성
  • 구현은 간단하게
  • 테스트를 통과하는 것에만 집중
• REFACTOR
  • 코드를 리팩토링
  • 테스트가 성공한 상태에서 코드를 개선하고 최적화

 

 

장점

• 설계 품질 향상
  • 테스트를 먼저 작성하므로 자연스럽게 테스트 가능한 구조와 명확한 설계
• 코드 안정성 증가
  • 기능 추가 시 기존 테스트가 깨지지 않으면 기존 코드가 안전하게 유지
• 빠른 피드백 제공
  • 개발 초기 단계에서 결함을 발견할 가능성이 높아져 문제 해결 비용이 줄어듦
• 유지보수성 개선
  • 테스트가 변경의 안전망 역할을 하므로 자신감 있게 코드를 수정
• 문서 역할 수행
  • 테스트는 코드의 동작을 명시적으로 보여주므로 자연스럽게 실행 가능한 문서

 

단점

• 초기 개발 속도 저하
  • 테스트 작성 시간 때문에 초기에 느리게 느껴짐
• 잘못된 테스트 작성 가능성
  • 초기에 테스트 설계가 잘못되면 오히려 혼란을 초래

 

 

예제

간단한 계산기(Calculator) 구현

 

요구사항

• 두 숫자의 합을 계산하는 기능을 제공한다.
• 두 숫자의 곱을 계산하는 기능을 제공한다.

 

1) RED

실패하는 테스트 작성

import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.api.Test;

class CalculatorTest {

    @Test
    void testAddition() {
        Calculator calculator = new Calculator();
        int result = calculator.add(2, 3);
        assertEquals(5, result);  // 기대값: 5
    }

    @Test
    void testMultiplication() {
        Calculator calculator = new Calculator();
        int result = calculator.multiply(2, 3);
        assertEquals(6, result);  // 기대값: 6
    }
}

=> 실패

 

2) GREEN

테스트를 통과시키기 위한 최소한의 코드 작성

class Calculator {
    public int add(int a, int b) {
        return a + b;
    }

    public int multiply(int a, int b) {
        return a * b;
    }
}

=> 성공

 

3) REFACTOR

• 코드 개선
• 복잡한 코드라면 이 단계에서 정리하거나 최적화
• 공통 로직을 분리하거나 불필요한 코드를 제거

 

언제 TDD를 사용하면 좋은가?

• 복잡한 비즈니스 로직
  • 계산, 조건, 상태 변화 등 테스트가 필요한 로직이 많을 때
• 장기적인 유지보수가 필요한 프로젝트
  • 기존 코드와의 통합에서 안정성이 중요한 경우

 

프로젝트에서 실제로 사용하면서 느낀 장점 중 하나는 문서 역할을 한다는 점이다. 테스트 코드만 봐도 기능의 의도와 동작을 쉽게 이해할 수 있어 새로운 개발자가 프로젝트에 합류하거나 과거 코드를 수정할 때 도움이 될것같다.

처음에는 TDD를 작성하는것이 익숙하지 않고 시간도 더 걸렸지만 장기적으로 더 좋은 코드와 유지보성을 보장해준다. 명확한 요구사항 없이 개발하는 초기 단계에서 오히려 비효율적인것 같다. 상황에 맞게 유연하게 활용해야할 것 같다.