189. BDD (Behavior-Driven Development)의 Given-When-Then 문법 명세

핵심 인사이트: 개발자는 코드로 말하고 기획자는 문서로 말하면 소통이 안 된다. BDD의 Given-When-Then 문법은 "어떤 상황에서(Given), 이런 행동을 하면(When), 이런 결과가 나와야 해(Then)"라는 일상 언어로 요구사항을 적어서, 기획자와 개발자, 그리고 자동화 테스트 도구까지 3자가 동시에 이해하는 기적의 번역기다.

Ⅰ. BDD (행위 주도 개발)와 유비쿼터스 언어

행위 주도 개발(Behavior-Driven Development)은 TDD(테스트 주도 개발)에서 파생된 기법으로, 테스트 자체가 '사용자가 시스템에서 기대하는 행동(Behavior)' 을 명세하는 문서가 되도록 하는 접근법입니다. 비개발자(PO, 기획자)와 개발자 모두가 이해할 수 있는 공통의 일상 언어(Ubiquitous Language)로 요구사항을 작성하는 것이 핵심입니다.

Ⅱ. Given-When-Then 구조 (Gherkin 문법)

BDD에서 요구사항(시나리오)을 명세하는 전 세계적인 표준 포맷이 바로 Gherkin(거킨) 문법의 Given-When-Then 구조입니다.

Feature: 장바구니 결제 (최상위 기능 명세)
  이커머스 고객으로서,
  선택한 상품을 한 번에 구매하기 위해,
  장바구니에 담은 물건들을 결제할 수 있어야 한다.

  Scenario: 장바구니에 잔액보다 비싼 물건 결제 시도 (구체적 테스트 시나리오)

    Given (주어진 상황 / 전제 조건)
      - 내 계좌의 잔액이 "50,000원"이다.
      - 장바구니에 "60,000원"짜리 상품이 담겨 있다.

    When (행동 / 이벤트 발생)
      - 사용자가 "결제하기" 버튼을 클릭한다.

    Then (기대되는 결과 / 검증)
      - 결제가 "실패"해야 한다.
      - 화면에 "잔액이 부족합니다"라는 에러 메시지가 표시되어야 한다.

Ⅲ. BDD 명세의 주요 장점

구분	설명
명확한 소통 (Living Documentation)	기획자가 쓴 요구사항 자체가 살아있는 문서가 됩니다. "버튼 누르면 안 넘어감" 같은 모호한 표현이 GWT 문법을 통해 명확한 인과관계로 정리됩니다.
자동화 테스트 연동	Cucumber(큐컴버)나 짓(JBehave) 같은 BDD 도구를 사용하면, 저 한글(또는 영어)로 적힌 텍스트 파일을 읽어 들여서 실제 코드로 자동 변환하여 테스트를 수행해 줍니다!
엣지 케이스 도출	"만약 계좌 정지 상태라면?(Given)", "결제 중에 뒤로 가기를 누르면?(When)" 등 다양한 예외 시나리오를 퍼즐 맞추듯 쉽게 찾아낼 수 있습니다.

Ⅳ. TDD (Test-Driven Development)와의 차이점

TDD (개발자 중심): "함수 add(1, 2)를 넣으면 3이 리턴되는가?" (단위 로직 중심, 코드로 작성)
BDD (비즈니스 중심): "고객이 상품 1개와 2개를 담으면 장바구니에 3개가 보이는가?" (사용자 행위 중심, 자연어로 작성)

📢 섹션 요약 비유: 보험 약관을 변호사(개발자)만 아는 어려운 법률 용어(코드)로 쓰는 것이 아니라, "고객이 병원에 입원한 상태에서(Given), 수술을 받으면(When), 수술비 전액을 보장받는다(Then)"라고 초등학생도 알아듣게 쓴 쉬운 약관입니다. 이 약관(문서) 자체가 재판(테스트)에서 100% 증거로 인정되는 완벽한 시스템입니다.