bdd-practices

name	bdd-practices
description	Writes behavior specifications in Gherkin format. Use when defining features from user perspective or creating acceptance tests.

BDD Practices

Gherkin 형식으로 기능을 명세하고, 선택적으로 자동화 테스트로 연결합니다.

핵심 철학:

• Feature First: .feature 명세 먼저, 구현 나중
• Specification by Example: 추상적 요구사항 대신 구체적 시나리오
• Living Documentation: .feature = 실행 가능한 문서 (자동화 없이도 가치 있음)

.feature 파일의 가치

.feature 파일 자체가:

• 요구사항 명세서 - Given/When/Then으로 구조화
• 인수 조건 (Acceptance Criteria) - 완료 기준 명확화
• 엣지 케이스 문서 - 예외 상황 정리
• 팀 커뮤니케이션 도구 - 비개발자도 읽을 수 있음

자동화 없이 명세로만 사용해도 충분한 가치가 있습니다.

Phase 1: Discovery (발견)

새 기능이나 요구사항 논의 시:

1. 요구사항 파악

   • 사용자가 요청한 기능을 명확히 이해
   • 모호한 부분은 사용자에게 질문

2. Example Mapping

   • 규칙(Rules)과 예시(Examples) 도출
   • 엣지 케이스 식별
   • 질문 목록 작성

3. 시나리오 목록 작성

   • 핵심 시나리오 나열 (Happy Path)
   • 예외 시나리오 나열 (Edge Cases)
   • 우선순위 기준:
     1. Happy Path (정상 플로우) - 가장 먼저
     2. 가장 흔한 예외 케이스
     3. 비즈니스 크리티컬 케이스
     4. 엣지 케이스 - 나중에
   • 예: "다음 시나리오들을 순서대로 진행하겠습니다: 1) 유효한 로그인, 2) 잘못된 비밀번호, 3) 존재하지 않는 사용자"

4. 사용자 확인

   • 시나리오 목록 보여주기
   • 누락된 케이스 확인

5. Phase 2로 진행

---

Phase 2: Formulation (명세화)

시나리오를 Gherkin 형식으로 작성: