BDD: 개념, 동작 시나리오 및 프레임워크

BDD란 무엇인가?

Behavior-Driven Development는 Dan North가 2006년에 테스트 공식화 문제에 대한 답변으로 제안한 TDD의 진화입니다. TDD에서 개발자는 테스트를 작성하지만 “정확히 무엇을 테스트할까?”라는 질문은 여전히 열려 있습니다. BDD는 코드 테스트에서 시스템 동작 설명으로 초점을 사용자 관점에서 전환하여 이 문제를 해결합니다.

BDD의 핵심 혁신은 모든 프로젝트 참가자를 위한 공통 언어입니다. 개발자, 테스터, 분석가 및 고객은 실행 가능한 테스트로도 기능하는 통합 언어로 시나리오를 논의합니다. 이는 분석가에서 개발자로 요구사항이 전달될 때 의미가 손실되는 고전적인 “ broken telephone” 문제를 제거합니다.

BDD의 역사

Dan North는 2006년 ThinkCode 블로그의 기사 “Introducing BDD”에서 BDD를 공식화했습니다. 그는 TDD의 테스트 이름이 종종 동작 용어(“사용자가 이메일로 등록할 수 있어야 함”)가 아닌 구현 용어(“testAddUser”)로 공식화된다는 것을 발견했습니다. BDD는 “test”를 “should”로, “assert”를 “expect”로 대체하여 사용자 가치에 초점을 옮겼습니다.

커뮤니케이션 실천으로서의 BDD

케임브리지 대학교의 연구(2021)에 따르면 고객 커뮤니케이션에 BDD 시나리오를 사용하는 프로젝트는 기존 텍스트 문서 사양과 비교하여 요구사항 오류를 35% 줄입니다. 실행 가능한 시나리오는 모호한 공식을 허용하지 않습니다 — 각 Given-When-Then은 통과하거나 실패합니다.

Gherkin 언어 및 구문

Gherkin은 Cucumber 및 SpecFlow 프레임워크가 동작 시나리오를 설명하는 데 사용하는 도메인 특화 언어입니다. Gherkin은 들여쓰기와 키워드를 사용하여 시나리오를 구조화하며 기술적 배경이 없는 사람도 읽을 수 있습니다.

Feature: Login
  Scenario: Successful login with valid credentials
    Given the user is on the login screen
    When they enter valid username and password
    Then they should see the home screen

Gherkin 키워드

Gherkin은 여러 기본 키워드를 정의합니다. Feature는 기능을 설명하고, Scenario는 특정 시나리오를 설명하고, Given은 전제 조건을 설명하고, When은 동작을 설명하고, Then은 예상 결과를 설명합니다. 추가로 And와 But은 여러 조건을 결합하는 데 사용됩니다.

.feature 파일 구조

Gherkin 파일의 확장자는 .feature이며 Android 프로젝트의 src/test/resources/features/ 디렉토리에 저장됩니다. 각 파일은 Feature 설명으로 시작하고 하나 이상의 Scenario가 뒤따릅니다. 매개변수화를 위해 Examples 테이블이 있는 Scenario Outline이 사용됩니다 — 이를 통해 동일한 시나리오를 다른 데이터로 실행할 수 있습니다.

Feature: Calculator
  Scenario Outline: Addition of two numbers
    Given the calculator is running
    When I add <a> and <b>
    Then the result should be <result>

    Examples:
      | a | b | result |
      | 2 | 3 | 5     |
      | 0 | 0 | 0     |
      | -1| 1 | 0     |

Given-When-Then 형식

Given-When-Then은 BDD가 도메인 주도 설계에서 채택한 시나리오 설명을 위한 구조적 패턴입니다. 각 시나리오는 세 부분으로 구성됩니다: 전제 조건, 동작, 예상 결과. 이 형식은 단위 테스트의 Arrange-Act-Assert에 자연스럽게 대응하지만 비즈니스 친화적인 언어를 사용합니다.

Given: 컨텍스트

Given 블록은 시나리오 시작 전 시스템 상태를 설명합니다: 어떤 데이터가 존재하는지, 어떤 구성 요소가 활성화되어 있는지, 애플리케이션이 어떤 모드로 작동하는지. 모바일 컨텍스트에서는 “사용자가 로그인함”, “장바구니가 비어 있지 않음” 또는 “장치가 오프라인 모드임”이 될 수 있습니다.

When: 동작

When 블록은 사용자 또는 시스템에 의해 트리거되는 이벤트를 설명합니다: 버튼 누르기, 푸시 알림 수신, 서버 응답. 모바일 애플리케이션에서 이는 종종 ViewModel 메서드 호출 또는 UI 요소 클릭에 해당합니다.

Then: 결과

Then 블록은 예상되는 상태 변화를 설명합니다: 화면 변경, API 호출, 데이터베이스 업데이트. Then의 검사는 측정 가능하고 명확해야 합니다 — 이는 실행 가능한 코드에서 assertion이 됩니다.

BDD와 TDD: 접근 방식 비교

BDD와 TDD는 종종 혼동되지만, 이는 다른 수준의 규율입니다. TDD는 코드 수준의 설계 기술: “구현을 작성하는 방법”입니다. BDD는 요구사항 수준의 사양 기술: “시스템이 해야 할 일”입니다.

프로젝트에서의 상호 보완

최고의 모바일 프로젝트는 개별 클래스 수준(도메인 계층)에서 TDD를 사용하고 시나리오 수준(기능 계층)에서 BDD를 사용합니다. 이는 이중 커버리지를 제공합니다: TDD는 구현 정확성을 보장하고 BDD는 요구사항 이해의 정확성을 보장합니다. Google은 내부 관행에서 Android 애플리케이션에 TDD와 BDD의 조합을 사용합니다(Android Testing 문서 2024).

모바일 개발을 위한 BDD 도구

BDD 생태계에는 모든 인기 모바일 개발 플랫폼 및 언어를 위한 프레임워크가 포함됩니다. 도구 선택은 기술 스택과 자동화 수준에 따라 달라집니다.

Android용 Cucumber

Cucumber는 가장 인기 있는 BDD 프레임워크로 Gherkin 시나리오와 함께 작동합니다. Android 프로젝트의 경우 io.cucumber:cucumber-android 라이브러리가 사용되며 Espresso 및 Compose Test UI 테스트 도구와 통합됩니다. Cucumber는 Kotlin과 Java를 지원하므로 두 언어를 모두 사용하는 스튜디오에 보편적인 선택입니다.

Xamarin용 SpecFlow

SpecFlow는 .NET 생태계를 위한 BDD 프레임워크로 Xamarin.Forms 및 .NET MAUI 프로젝트에서 사용됩니다. SpecFlow는 NUnit 및 xUnit과 통합되며 step definitions은 C#으로 작성됩니다. 모바일 프로젝트의 경우 SpecFlow는 공유 코드베이스에서 애플리케이션의 Android 및 iOS 버전 간에 시나리오를 재사용할 수 있습니다.

iOS용 Quick/Nimble

Swift로 iOS 개발을 위한 BDD 프레임워크로 Quick과 Nimble이 있습니다. Quick은 describe/it 스타일로 시나리오를 설명하는 DSL을 제공하고 Nimble은 읽기 쉬운 구문의 매처를 제공합니다. 이러한 프레임워크는 Gherkin을 직접 사용하지 않지만 BDD 원칙을 구현합니다: 전체 팀이 이해할 수 있는 언어로 동작을 설명하는 것입니다.

BDD 시나리오 및 코드 예제

Android 프로젝트의 완전한 BDD 예제를 살펴보겠습니다: 주문 체크아웃 시나리오. 먼저 Gherkin 시나리오를 작성한 다음 Kotlin으로 step definitions을 작성합니다.

BDD 작동 원리: three amigos

BDD 방법론은 three amigos 회의를 기반으로 합니다 — 세 가지 역할: 개발자, 테스터, 분석가. 그들은 개발 시작 전에 함께 시나리오를 작성하여 요구사항에 대한 공통된 이해를 확립합니다. 세 참가자 중 한 명이라도 시나리오를 이해하지 못하면 요구사항이 모호하게 공식화되었음을 의미합니다. 이 관행은 “Discovery: Explore Behaviour Using Examples”(Gáspár & North, 2021) 책에 설명되어 있으며 성숙한 팀의 BDD 프로세스에서 필수적인 부분입니다.

Gherkin 시나리오: 주문 체크아웃

Feature: Order Checkout
  Scenario: Apply promo code to cart
    Given the user has items in the cart
    And the total amount is $100
    When they apply promo code "WELCOME10"
    Then the discount should be $10
    And the final total should be $90

Kotlin의 Step Definitions

Step definitions은 Gherkin 시나리오를 테스트 구현과 연결하는 코드입니다. 각 단계는 Gherkin 키워드에 해당하는 주석이 있는 메서드입니다.

class CheckoutSteps {
    private val cart = Cart()
    private val checkout = CheckoutUseCase()

    fun `user has items in the cart`() {
        cart.addItem(Item("Phone", 100.0))
    }

    fun `apply promo code`(code: String) {
        checkout.applyPromo(cart, code)
    }

    fun `discount should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getDiscount())
    }

    fun `final total should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getTotal())
    }
}

Cucumber Android와의 통합

Android 프로젝트에서 BDD 테스트를 실행하려면 CucumberAndroidJUnitRunner가 사용됩니다. 리소스에서 .feature 파일을 스캔하고 정규 표현식으로 해당 step definitions을 찾아 시나리오를 일반 계측 테스트로 실행합니다. 결과는 고객이 이해할 수 있는 HTML 보고서로 형식화됩니다.

// build.gradle.kts
dependencies {
    androidTestImplementation("io.cucumber:cucumber-android:7.18.0")
    androidTestImplementation("io.cucumber:cucumber-junit:7.18.0")
}

// CucumberOptions annotation
@RunWith(Cucumber::class)
@CucumberOptions(features = "features", glue = ["com.app.steps"])
class CucumberTestRunner

모바일 프로젝트에서 BDD 도입의 어려움

모바일 개발에 BDD를 도입하는 것은 여러 실질적인 어려움을 수반합니다. 이러한 문제를 이해하면 팀이 좌절을 피하고 지속 가능한 BDD 프로세스를 구축하는 데 도움이 됩니다.

.feature 파일 유지 관리

주요 문제는 Gherkin 시나리오와 프로덕션 코드 간의 비동기화입니다. 개발자가 step definitions을 업데이트하지 않고 API를 변경하면 .feature 파일이 구현과 일치하지 않습니다. 해결책은 CI/CD 파이프라인에서 BDD 테스트를 실행하고 병합 요청에 대해 녹색 상태를 요구하는 것입니다. “BDD as a gating mechanism” 관행은 Cucumber 문서(2024)에 설명되어 있으며 업계 표준입니다.

BDD 테스트 성능

Cucumber의 BDD 시나리오는 Android 기기 또는 에뮬레이터에서 계측 테스트로 실행됩니다. 이는 JVM의 일반 단위 테스트보다 10~50배 느립니다. 대규모 Android 애플리케이션의 경우 단일 수락 테스트에 20~30분이 소요될 수 있습니다. BDD 테스트는 별도의 CI 작업에서 야간에 실행하고 단위 테스트는 모든 push에서 실행하는 것이 좋습니다. 이 전략은 피드백 속도와 시나리오 커버리지의 균형을 맞춥니다.

Gherkin 팀 교육

BDD로의 전환은 개발자뿐만 아니라 분석가와 테스터의 교육도 필요합니다. Gherkin은 간단한 언어이지만 좋은 시나리오를 작성하려면 연습이 필요합니다. 초보자의 일반적인 실수: 너무 긴 시나리오(10단계 초과), Given-When-Then 혼합, 비즈니스 시나리오에서 기술 용어 사용. BDD Academy(2024)에 따르면 팀이 BDD 시나리오 작성에 성숙해지는 데 평균 4~6 스프린트가 필요합니다.