행위 주도 개발(BDD)

행위 주도 개발(Behavior-Driven Development, BDD)은 코드를 작성하기 전에 공통의 이해를 쌓는 방법입니다. 기획, 개발, 테스트(흔히 “쓰리 아미고”라고 부릅니다)가 기능이 어떻게 동작해야 하는지 구체적인 예시를 들어 논의합니다. 이 예시가 인수 조건이 되고, 많은 팀은 이를 Cucumber, SpecFlow의 후속 도구인 Reqnroll, Behave 같은 도구로 실행 가능한 명세(executable specification)로 자동화합니다.

예시

할인 규칙에 대한 대화는 다음과 같은 예시로 정리됩니다.

Feature: Loyalty discount

  Scenario: Gold members get 10% off orders over 100
    Given a customer with Gold membership
    When they check out a basket worth 120.00
    Then the order total is 108.00

  Scenario: The discount does not apply at exactly 100
    Given a customer with Gold membership
    When they check out a basket worth 100.00
    Then the order total is 100.00

가치 있는 쪽은 두 번째 시나리오입니다. 이 시나리오를 쓰다 보면 누군가 잘못된 것을 만들기 전에 “100 초과인가, 100 이상인가?“라는 질문을 할 수밖에 없습니다.

세 가지 실천 단계

1. 디스커버리(Discovery). 예시를 통해 기능을 탐색하고 엣지 케이스와 미결 질문을 찾습니다.
2. 포뮬레이션(Formulation). 합의된 예시를 비즈니스 담당자도 읽을 수 있는 구조화된 형식, 보통 Gherkin으로 작성합니다.
3. 자동화(Automation). 각 스텝을 코드에 바인딩해 예시가 테스트로 실행되고 살아 있는 문서(living documentation) 역할을 하게 합니다.

흔한 실수

• BDD를 테스트 도구로만 취급하기. 대화 없이 혼자서 코드 작성 후에 Gherkin을 쓰면, 공통 이해라는 이점은 없이 번역 계층의 비용만 떠안게 됩니다.
• UI 수준의 스텝. “When I click the button with id submit”은 동작이 아니라 인터페이스를 설명합니다. 스텝은 화면을 다시 디자인해도 살아남아야 합니다.
• 모든 시나리오를 브라우저로 자동화하기. 위의 할인 같은 비즈니스 규칙은 대개 API나 서비스 계층에서 자동화하는 편이 더 빠르고 안정적입니다.
• 거대한 스텝 라이브러리. 조금씩 다른 스텝 정의가 수백 개 있으면 유지보수가 어렵습니다. 어휘는 작게, 도메인 중심으로 유지하세요.

BDD는 비즈니스 담당자가 실제로 시나리오를 읽고 기여할 때 잘 작동합니다. 엔지니어링 외부에서 아무도 보지 않는다면, 이름을 잘 지은 일반 테스트 코드가 더 간단한 경우가 많습니다.