[ 방법론 ] TDD vs BDD vs ATDD

먼저, 이 3개의 개발 방법론의 핵심적인 차이는 "테스트 레벨"이 다르다는 것에 집중해야 한다. 즉, 서로가 서로의 대체재는 아니라는 뜻 이다.

 

• TDD, Test-Driven Development
  • 코드 수준에서 "이 로직은 이렇게 동작해야만해!!!!" 를 고정.
• BDD, Behavior-Driven Development
  • 사용자/비즈니스 수준에서 "이 기능은 이런 행동을 해야만 해 !!!"를 "언어"로 고정
• ATDD, Acceptance Test-Driven Development
  • 이해관계자가 합의한 인수기준을 고정!

 

음. 내가 적었지만 이해가 안간다. 사실 그게 그거 같다. 좀 더 자세히적어보자.

 

1) TDD

목적:  설계를 테스트 가능하게 만들기.

테스트를 먼저 쓰며 Red → Green → Refactor 사이클을 돌린다고 생각! 주로 단위 테스트 중심이다.

실제로는 자동화된 테스트가 실패했다? 그럴때만 다시 코드를 다시 작성한다고 보면 된다.

 

그렇다고, TDD와 단위테스트가 같다고 보면 안된다. 둘은 목적이 다르다.

 

추가로 Red Green Refactor가 무엇인지 모르시는 분들을 위해 초간단하게 적어보자면,

🔴 Red: 실패하는 테스트 먼저

// CalcTest.java
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;

class CalcTest {
    @Test
    void addsTwoCommaSeparatedNumbers() {
        assertEquals(3, Calc.add("1,2"));
    }
}


// Calc.jaava
public class Calc {
    public static int add(String s) {
        return 0; // 일부러 틀리게: 테스트 실패(Red)
    }
}

🟢 Green: 최소 구현으로 통과

// Calc.java
public class Calc {
    public static int add(String s) {
        String[] parts = s.split(",");
        return Integer.parseInt(parts[0]) + Integer.parseInt(parts[1]);
    }
}

🔵 Refactor: 테스트는 그대로 통과 + 더 깔끔/확장 가능하게 재구성

// Calc.java
public class Calc {
    public static int add(String s) {
        int sum = 0;
        for (String p : s.split(",")) {
            sum += Integer.parseInt(p);
        }
        return sum;
    }
}

 

2) BDD

목적: “우리가 뭘 만들고 있는지”를 모두가 같은 그림으로 이해하도록 행동 중심으로 명세
‘테스트’보단 행동 명세 + 협업 방식 성격이 강하다고 한다. 주로 시나리오(Given-When-Then) 형태로 표현

3) ATDD (Acceptance Test-Driven Development)

목적: 기능 개발 전에 수용 기준을 명확히 합의하고, 그것을 테스트로 정의해 “완료의 정의”를 만들기.
“개발 완료”를 판단하는 인수 테스트를 먼저 정의해서, 사용자 가치/비즈니스 목표와 개발을 직접 연결

 

 

슬슬 윤곽이 잡힌다..! ( 나만 ㅎ )

 

 

TDD는 코드만 돌아가면 ok , BDD는 시나리오가 돌아가면 ok, ATDD는 최종보스를 만족하면 ok

 

예시를 들어보자.

 

조건 : 재고가 0이면 주문이 실패해야 한다.

 

TDD

- Stock.reserve(productId, qty) 호출 -> 재고 부족 -> 예외/결과 코드 리턴

- 즉, 경계값 ( qty =1, stock=0 ) 케이스를 꼼꼼히 체크

BDD

- Given ( 재고가 0인 상품이 있고 ) , When ( 사용자가 그 제품을 주문하면 ) , Then ( 품절 메시지를 띄우고, 주문을 생성하지 않음 )

 

ATDD

- 수용 기준 ( 재고 < 주문수량 -> 주문 생성 x ) 

- 결제 요청 x

- 사용자에게 품절 알림

→ 완료 판정 기준이 명확해지고, 누락(결제 호출 같은 치명적 실수)을 잡기 좋음

 

마무리

도입부에서 언급했듯이 각각의 방법론은 경쟁적인, 대체재가 되는 방법론이 아니다. 각자만의 장단점이 있다. 예를 들어 TDD는 리팩토링이 잦고 핵심 로직인 부분에 강하고, BDD는 이해관계자가 많아서 오해 비용이 큰 곳, ATDD는 완료 기준이 자주 흔들리는 곳에서 강하다! 즉 서로 장점만을 살리며 혼합해서 사용할 수 있다.

 

급한 분들을 위해서 초간단 표

구분	TDD	BDD	ATDD
한 줄 요약	만들기 전에 테스트를 먼저 씀	만들 기능을 행동 예시(주로 자연어)로 먼저 정함.	통과 기준을 먼저 정함 ( 이 기준 통과하면 너 인수 해가는거다? )
포커스	코드가 제대로 작동	사용자에게 보이는 동작	요구 조건 만족
주로 하는 사람	개발자	기획자 + 개발자	기획자
좋은 점	버그가 줄고, 수정이 빠름(피드백이 빨리빨리 돌 수 있음 ! )	오해가 줄고, 요구 명확함	완료 기준이 명확함
리스크 ( 주의점 )	요구를 잘못 잡으면 헛수고	문서가 늘어서 관리가 힘듦	테스트가 느려질 수 있음( 합의하다가.. )