BDD(Behavior-Driven Development)

BDD

BDD란 개발자와 비개발자간의 협업을 강조하는 Agile 소프트웨어 방법론으로 애플리케이션의 예상 동작을 사람이 읽을 수 있는 시나리오를 기반으로 다른 팀들 간의 커뮤니케이션 격차를 해소하고 소프트웨어 요구 사항에 대한 이해를 공유합니다.
BDD는 TDD(Test-Driven Development)와 DDD(Domain-Drvien Design)에서 파생된 개발 방법론으로 주로 동작보다는 테스트 구현에 중점을 둡니다. 소프트웨어의 예상 동작에 초첨을 맞춰 행위를 작성하고 결과를 검증함으로써 행위 중심의 도메인 기반 설계 방법입니다. BDD는 특히 해결해야 할 비즈니스 문제가 복잡할 때 효과적인 개발 방법론으로 간주됩니다.

Agile과의 관계
BDD를 사용하면 응용 프로그램 수준에서 포괄적인 문서보다 작동하는 소프트웨어를 보장하는 문서를 얻을 수 있습니다.

또한 BDD는 다음 아래와 같은 원칙을 따릅니다.

1. 협업: 이해 관계자, 개발자 및 테스터 간의 상호 작용을 장려합니다.
2. 유비쿼터스 언어: 인간이 읽을 수 있는 공통 언어를 사용하여 소프트웨어 동작을 설명합니다.
3. 테스트 주도 개발: 실제 코드를 작성하기 전에 예상 동작을 기반으로 테스트를 작성합니다.

Behavioral Specifications

BDD는 비개발자와 개발자가 협력하는 하며 각각 전용 문서에 명시적으로 기록되는 사용자 스토리 측면에서 동작을 지정해야 합니다. 사용자 스토리를 정확히 어떻게 작성해야 하는지에 대한 공식적인 표준은 없지만 BDD를 창시한 Dan North가 2007년에 아래와 같은 템플릿을 제안했습니다.

Format

• Title(제목)
  명시적인 제목
• Narrative(이야기) 다음 구조의 짧은 소개 섹션을 작성합니다.
  • As a: 기능의 혜택을 받을 사람 또는 역할
  • I want: 기능
  • so that: 기능의 이점 또는 가치
• Acceptance Criteria(허용 기준)
  다음 구조를 사용하여 특정 시나리오에 대한 설명합니다.
  • Given: 시나리오 상에서 주어진 환경의 정의
  • When: 사용자의 행위에 대한 정의
  • Then: 그에 따른 결과를 정의

Example of This Format

• Title: 반품과 교환은 재고로 추가돼야합니다.
  • As a: 점주
  • I want: 반품 또는 교환 시 재고에 다시 추가 되어야 합니다.
  • so that: 다시 팔 수 있습니다.
• Scenario 1: 환불된 상품은 다시 재고에 추가 되어야 합니다.
  • given: 고객이 이전에 나에게서 검은색 스웨터를 구입했습니다.
  • and 3개의 검은색 스웨터가 재고 목록에 있습니다.
  • when: 고객은 환불을 위해 검은 스웨터를 돌려줍니다.
  • then: 나는 총 4개의 검은색 스웨터가 재고 목록에 있어야합니다.
• Scenario 2: 교환된 상품은 다시 재고에 추가 되어야 합니다.
  • given: 이전에 어떤 고객이 나에게서 파란색 옷을 구입했습니다.
  • and 2개의 파란색 옷이 재고 목록에 있습니다.
  • and 3개의 검은색 옷이 재고 목록에 있습니다.
  • when: 고객은 파란색 옷을 검은색 옷으로 교환했습니다.
  • then: 나는 총 3개의 파란색 옷이 재고 목록에 있어야합니다.
  • and: 2개의 검은색 옷이 재고 목록에 있어야합니다.

위와 같이 시나리오는 상호 작용이 발생하는 UI 요소에 대한 참조 없이 비즈니스 언어로 명령형이 아닌 선언형으로 표현됩니다.

BDD는 DDD의 유비쿼터스 언어 개념을 차용해 소프트웨어 개발자와 비기술 인력 모두를 포함한 소프트웨어 개발 팀의 모든 구성원이 소프트웨어 도메인을 논의하는 공통 수단으로 모든 팀 구성원이 사용하고 개발합니다. BDD는 소프트웨어 프로젝트에서 서로 다른 모든 역할 간의 통신 수단으로서 개발자와 비즈니스 이해 관계자 간의 통신 단절을 방지하고 사양이 공식적으로 추론될 수 있도록 돕습니다.

TDD & BDD

TDD와 BDD는 서로 상호보완적인 관계에 있습니다. BDD는 협업 및 커뮤니케이션을 개선하기 위한 방법론으로 비즈니스 목표와 고객 요구 사항을 모두 충족하고 애플리케이션 및 요구 사항 수준에서 작동합니다. 하지만 TDD의 주요 관심사는 코드 수준의 설계 및 사양에 관한 것기 때문에 “BDD의 테스트 통과” 단계에서 사용할 수 있습니다. BDD로 어떠한 행위를 테스트하고 해당 행위에 대한 코드 레벨에서 TDD를 사용하여 코드를 설계해 나갈 수 있습니다.

오탈자 및 오류 내용을 댓글 또는 메일로 알려주시면, 검토 후 조치하겠습니다.