TDD 대 BDD 논쟁은 종종 한쪽을 선택하는 것으로 구성됩니다. 실제로 그들은 다른 질문에 대답합니다. 테스트 중심 개발은 코드가 개발자가 의도한 대로 작동하는지 여부를 묻는 반면, 행동 중심 개발은 소프트웨어가 수행해야 하는 작업에 대해 팀이 동의하는지 여부를 묻습니다.

차이점을 구체적으로 만들기 위해 각 접근 방식에 대해 하나의 작은 할인 기능을 구축합니다. 표준 라이브러리를 사용하여 Python 3.13에서 코드를 실행했으며 아래 결과는 해당 실행에서 나온 것입니다. BDD 부분은 메커니즘을 보여주기 위해 우리 자신의 작은 러너를 사용하므로 실제 프로젝트에서는 Cucumber와 같은 도구를 사용하거나 대신 작동합니다.

짧은 대답

테스트 중심 개발(TDD)은 코딩 관행입니다. 작은 실패 테스트를 작성하고 가장 간단한 코드로 테스트를 통과시킨 다음 디자인을 개선합니다. 테스트는 주로 개발자가 코드로 작성합니다. Kent Beck은 이 관행을 대중화했습니다.

행동 중심 개발(BDD)은 TDD에서 발전한 협업 관행이며 Dan North가 이 용어를 도입했습니다. 개발자, 테스터 및 비즈니스 담당자는 시스템이 어떻게 작동해야 하는지에 대한 예에 동의하고 일반 언어로 작성되며 해당 예는 자동화될 수 있습니다.

TDD와 BDD를 나란히 놓고

특징

우리가 구현할 비즈니스 규칙은 다음과 같습니다. 1000개 이상 주문 시 10% 할인을 받습니다. 회원은 해당 주문에 대해 추가로 5% 할인을 받을 수 있습니다.

분명하게 들릴 수도 있지만 이미 모호합니다. 500불 구매 회원은 5% 할인을 받을 수 있나요? 문장에는 “그 명령”이라고 적혀 있으므로 그렇지 않다고 가정합니다. BDD가 조기에 제기하도록 설계된 질문이 바로 이것이기 때문입니다.

TDD로 빌드하기

TDD는 빨간색, 녹색, 리팩터링이라는 짧은 루프를 따릅니다.

다음은 각 규칙에 대해 하나씩 테스트하는 것입니다.

class DiscountTests(unittest.TestCase):
    def test_no_discount_below_1000(self):
        self.assertEqual(discount(999, False), 0)

    def test_ten_percent_from_1000(self):
        self.assertEqual(discount(1000, False), 100)

    def test_member_gets_extra_five_percent(self):
        self.assertEqual(discount(1000, True), 150)

그런 다음 세 단계로 코드를 작성하고 각 단계마다 테스트를 실행했습니다. 엄격한 TDD 세션은 한 번에 하나의 테스트를 추가하며 이는 동일한 진행을 보여줍니다.

1단계: 가장 간단한 것

def discount(total, is_member):
    return 0

# 3 tests, 2 failed
#   test_member_gets_extra_five_percent
#   test_ten_percent_from_1000

0을 반환하는 것은 어리석은 것처럼 보이지만 테스트가 실제로 실패할 수 있음을 증명하며 통과한 테스트 중 하나는 “할인 없음” 규칙입니다.

2단계: 임계값 추가

def discount(total, is_member):
    if total >= 1000:
        return total * 0.1
    return 0

# 3 tests, 1 failed
#   test_member_gets_extra_five_percent

3단계: 구성원 추가 및 정리

def discount(total, is_member):
    rate = 0.1 if total >= 1000 else 0
    if is_member:
        rate += 0.05
    return round(total * rate, 2)

# 3 tests, 0 failed

세 가지 모두 통과합니다. 하지만 이 버전을 자세히 읽어보세요. 이는 500을 지출하는 회원에게 5% 할인을 제공하는데, 이는 규칙이 의미하는 바가 아닙니다. 해당 사례를 다루는 테스트가 없었기 때문에 아무 것도 표시되지 않았습니다. TDD는 테스트하려고 생각한 동작만 보호합니다. 이는 실제 제한 사항이며 예제에 대한 대화가 그토록 중요한 이유입니다.

주기가 중요한 이유

• 빨간색은 테스트가 작동한다는 것을 증명합니다. 한 번도 실패한 테스트는 아무것도 테스트하지 않을 수 있습니다.
• 녹색은 집중을 유지합니다. 필요한 코드만 작성하므로 과도한 엔지니어링을 방지하는 데 도움이 됩니다.
• 리팩터링을 통해 품질을 높게 유지합니다. 테스트를 통해 디자인을 안전하게 변경할 수 있다는 자신감을 얻을 수 있습니다.
• 디자인에 영향을 줍니다. 테스트하기 어려운 코드는 너무 긴밀하게 결합되어 있는 경우가 많으며 즉시 알아챌 수 있습니다.

우리의 pytest 튜토리얼은 이와 같은 테스트를 작성하는 더 편리한 방법을 보여주고, 경계 값 분석은 우리가 999와 1000을 값으로 선택한 이유를 설명합니다.

BDD로 빌드하기

BDD는 도구가 아닌 대화로 시작됩니다. 종종 이는 제품 담당자, 개발자 및 테스터가 구체적인 예를 논의하는 세 친구로 알려진 짧은 회의입니다.

Tester:  What about a member spending 500?
Product: Good question. No discount. It has to reach 1000 first.
Dev:     And exactly 1000 counts?
Product: Yes, 1000 or more.

그 교환 하나가 우리 TDD 코드의 문제를 포착했을 것입니다. 그런 다음 Gherkin이라는 구조화된 형식으로 예제를 기록합니다.

Feature: Order discounts

  Scenario: Member reaches the discount threshold
    Given a member with a cart worth 1000
    When they view the amount to pay
    Then the amount to pay is 850

  Scenario: Member below the threshold gets no discount
    Given a member with a cart worth 500
    When they view the amount to pay
    Then the amount to pay is 500

팀원 누구나 그것을 읽고 “예, 맞습니다” 또는 “아니요, 그건 틀렸습니다”라고 말할 수 있습니다. 자동화하지 않더라도 시나리오는 이미 유용한 작업을 수행했습니다.

단계를 코드에 연결하기

도구는 각 일반 언어 행을 단계 정의라고 하는 함수에 연결합니다. 아이디어를 보여주기 위해 우리는 작은 버전을 직접 작성하고 첫 번째 시나리오를 실행했습니다.

@step("a member with a cart worth 1000")
def given(ctx):
    ctx["cart"] = Cart(is_member=True)
    ctx["cart"].add(1000)

@step("they view the amount to pay")
def when(ctx):
    ctx["amount"] = ctx["cart"].payable()

@step("the amount to pay is 850")
def then(ctx):
    assert ctx["amount"] == 850

# ok Given a member with a cart worth 1000
# ok When they view the amount to pay
# ok Then the amount to pay is 850

실제 도구는 매개변수를 추가하므로 단일 단계가 “1000” 및 “500”과 보고 기능을 모두 일치시킬 수 있습니다. 그 결과는 살아있는 문서입니다. 즉, 사실이 아닌 경우 크게 실패하는 시스템에 대한 간단한 설명입니다.

좋은 시나리오 쓰기

클릭 수와 필드 ID를 설명하는 시나리오는 재설계할 때마다 중단되며 비즈니스 독자는 해당 시나리오 읽기를 중단합니다. 단계 코드에 사용자 인터페이스 세부정보를 유지합니다. 이러한 시나리오는 테스트 사례와 테스트 시나리오의 예제와 가까운 사촌이며 사용자 승인 테스트에도 자주 사용됩니다.

둘 다 함께 사용

두 가지 방법은 자연스럽게 “외부-내부” 작업 흐름에 적합합니다.

1. 팀은 행동에 동의하고 BDD 시나리오를 작성합니다. 아직 아무것도 존재하지 않기 때문에 실패합니다.
2. 개발자는 TDD를 사용하여 필요한 작은 단위를 구축합니다.
3. 단위 테스트가 통과되고 결국 시나리오도 통과됩니다.
4. 모든 것이 CI/CD 파이프라인에서 실행됩니다.

각각을 올바른 수준으로 유지하십시오. 중요한 동작에 대한 몇 가지 시나리오와 세부 사항에 대한 빠른 단위 테스트가 많이 있어야 합니다. 단위 테스트와 통합 테스트에 대한 가이드에서는 균형을 다룹니다.

도구

각각을 사용하는 경우

TDD는 다음과 같은 경우에 적합합니다.

• 가격 책정, 구문 분석 또는 권한과 같은 복잡한 논리를 작성하고 있습니다.
• 실패한 테스트를 통해 먼저 버그를 재현할 수 있으므로 버그를 수정하는 것입니다.
• 당신은 자주 변경되는 코드를 작업하고 있습니다.

BDD는 다음과 같은 경우에 적합합니다.

• 비즈니스 규칙은 복잡하고 오해로 인해 비용이 많이 듭니다.
• 기술적인 지식이 없는 사람들도 실제로 시나리오를 읽고 토론할 것입니다.
• 여러 팀에서는 사물의 작동 방식에 대한 공유 정의가 필요합니다.

다음과 같은 경우에는 과잉일 수 있습니다. 일회용 프로토타입을 작성하거나 불분명한 기술 아이디어를 탐구하는 경우입니다. 많은 개발자가 먼저 급증한 다음 테스트를 통해 다시 작성합니다. 엔지니어링 외부의 누구도 시나리오를 살펴보지 않는다면 BDD 도구는 잘못된 투자이기도 합니다. 이 경우 좋은 이름을 사용한 일반 테스트가 더 간단합니다.

일반적인 실수

• BDD를 테스트 도구로 사용합니다. 공동 작업이 없는 오이는 테스트를 작성하는 장황한 방법일 뿐입니다.
• TDD의 테스트 구현. 비공개 세부정보와 연결된 테스트는 리팩토링할 때마다 중단됩니다.
• 리팩터링 단계를 건너뜁니다. 지저분한 코드 위에서 테스트를 통과하게 됩니다.
• 코드 다음에 테스트를 작성하고 이를 TDD라고 부릅니다. 이는 여전히 유용하지만 디자인 피드백을 잃게 됩니다.
• UI 시나리오를 너무 많이 작성합니다. 속도가 느리고 불안정해집니다. 불안정한 테스트를 참조하세요.
• 적용 범위를 쫓는 것. 우리의 예에서 볼 수 있듯이 좋은 적용 범위는 여전히 아무도 고려하지 않은 행동을 놓치고 있습니다.

마무리

TDD는 올바른 것을 구축하는 데 도움이 되고 BDD는 올바른 것을 구축하는 데 도움이 됩니다. 우리의 할인 예는 양면을 보여주었습니다. 코드는 모든 테스트를 통과했지만 간단한 대화에서는 잘못된 가정이 드러났습니다. 다음 작은 기능에 사용해 보세요. 코드를 작성하기 전에 동료와 함께 세 가지 구체적인 예를 작성한 다음 한 번에 하나의 실패한 테스트를 빌드하세요.

자주 묻는 질문

계속 학습하세요