BDD: What It Is, Behavior Scenarios and Frameworks

What is BDD?

Behavior-Driven Development is an evolution of TDD proposed by Dan North in 2006 as an answer to the problem of test formulation. In TDD, the developer writes a test, but the question “what exactly to test?” remains open. BDD solves this problem by shifting the focus from testing code to describing system behavior from the user’s perspective.

The key innovation of BDD is a common language for all project participants. Developers, testers, analysts, and clients discuss scenarios in a unified language that simultaneously serves as an executable test. This eliminates the classic “broken telephone” problem where requirements lose meaning when passed from analyst to developer.

The History of BDD

Dan North formulated BDD in 2006 in his article “Introducing BDD” on the ThinkCode blog. He noticed that test names in TDD are often formulated in implementation terms (“testAddUser”) rather than behavior terms (“user should be able to register with email”). BDD replaced the word “test” with “should” and “assert” with “expect”, shifting the focus to user value.

BDD as a Communication Practice

According to a Cambridge University study (2021), projects using BDD scenarios in client communication reduce requirement errors by 35% compared to traditional text-based specifications. Executable scenarios do not allow ambiguous formulations — each Given-When-Then either passes or fails.

Gherkin Language and Syntax

Gherkin is a domain-specific language used by Cucumber and SpecFlow frameworks to describe behavior scenarios. Gherkin uses indentation and keywords to structure scenarios while remaining readable for people without a technical background.

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 Keywords

Gherkin defines several basic keywords. Feature describes functionality, Scenario describes a specific scenario, Given describes preconditions, When describes the action, Then describes the expected result. Additionally, And and But are used to combine multiple conditions.

.feature File Structure

Gherkin files have the .feature extension and are stored in the src/test/resources/features/ directory in Android projects. Each file starts with a Feature description, followed by one or more Scenarios. For parameterization, Scenario Outline with Examples tables is used — this allows running the same scenario with different data.

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 Format

Given-When-Then is a structural pattern for describing scenarios, adopted by BDD from domain-driven design. Each scenario consists of three parts: preconditions, action, and expected result. This format naturally corresponds to Arrange-Act-Assert from unit testing but uses business-friendly language.

Given: Context

The Given block describes the system state before the scenario begins: what data exists, which components are active, what mode the application is in. In a mobile context, this could be “the user is logged in”, “the cart is not empty”, or “the device is in offline mode”.

When: Action

The When block describes an event triggered by the user or system: pressing a button, receiving a push notification, server response. In mobile applications, this often corresponds to calling a ViewModel method or clicking a UI element.

Then: Result

The Then block describes the expected state change: screen change, API call, database update. Checks in Then must be measurable and unambiguous — they become assertions in executable code.

BDD and TDD: A Comparison of Approaches

BDD and TDD are often confused, although they are different levels of discipline. TDD is a design technique at the code level: “how to write the implementation”. BDD is a specification technique at the requirements level: “what the system should do”.

Complementarity in a Project

The best mobile projects use TDD at the individual class level (domain layer) and BDD at the scenario level (feature layer). This provides double coverage: TDD guarantees implementation correctness, BDD guarantees correctness of requirement understanding. Google uses a combination of TDD and BDD for Android applications in its internal practice, as stated in the Android Testing documentation (2024).

BDD Tools for Mobile Development

The BDD ecosystem includes frameworks for all popular mobile development platforms and languages. The choice of tool depends on the technology stack and automation level.

Cucumber for Android

Cucumber is the most popular BDD framework, working with Gherkin scenarios. For Android projects, the io.cucumber:cucumber-android library is used, which integrates with Espresso and Compose Test UI testing tools. Cucumber supports Kotlin and Java, making it a universal choice for studios using both languages.

SpecFlow for Xamarin

SpecFlow is a BDD framework for the .NET ecosystem, used in Xamarin.Forms and .NET MAUI projects. SpecFlow integrates with NUnit and xUnit, and its step definitions are written in C#. For mobile projects, SpecFlow allows reusing scenarios between Android and iOS versions of the application on a shared codebase.

Quick/Nimble for iOS

For iOS development in Swift, there are BDD frameworks Quick and Nimble. Quick provides a DSL for describing scenarios in the describe/it style, and Nimble provides matchers with readable syntax. Although these frameworks do not use Gherkin directly, they implement the BDD principle: describing behavior in a language understandable to the whole team.

BDD Scenario and Code Examples

Let’s look at a complete BDD example in an Android project: an order checkout scenario. First we write a Gherkin scenario, then step definitions in Kotlin.

BDD Working Principle: Three Amigos

The BDD methodology is based on the three amigos meeting — three roles: developer, tester, and analyst. They collaboratively write scenarios before development begins, establishing a shared understanding of requirements. If even one of the three participants doesn’t understand the scenario, it means the requirement is ambiguously formulated. This practice is described in the book “Discovery: Explore Behaviour Using Examples” (Gáspár & North, 2021) and is a mandatory part of the BDD process in mature teams.

Gherkin Scenario: Order Checkout

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

Step Definitions in Kotlin

Step definitions are code that connects Gherkin scenarios with test implementation. Each step is a method with an annotation corresponding to a Gherkin keyword.

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())
    }
}

Integration with Cucumber Android

To run BDD tests in an Android project, CucumberAndroidJUnitRunner is used. It scans .feature files in resources, finds corresponding step definitions by regular expressions, and executes scenarios as regular instrumented tests. Results are formatted into an HTML report understandable to the client.

// 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

Challenges of Adopting BDD in Mobile Projects

Adopting BDD in mobile development comes with several practical difficulties. Understanding these challenges helps teams avoid frustration and build a sustainable BDD process.

.feature File Maintenance

The main problem is desynchronization between Gherkin scenarios and production code. If developers change APIs without updating step definitions, .feature files stop matching the implementation. The solution is to run BDD tests in the CI/CD pipeline and require green status for merge requests. The practice of “BDD as a gating mechanism” is described in Cucumber documentation (2024) and is an industry standard.

BDD Test Performance

BDD scenarios in Cucumber run as instrumented tests on an Android device or emulator. This is 10–50 times slower than regular unit tests on the JVM. A single acceptance test suite can take 20–30 minutes for a large Android application. It is recommended to run BDD tests in a separate CI job at night, while unit tests run on every push. This strategy balances feedback speed and scenario coverage.

Team Training in Gherkin

Transitioning to BDD requires training not only developers but also analysts and testers. Gherkin is a simple language, but writing good scenarios requires practice. Typical beginner mistakes: overly long scenarios (more than 10 steps), mixing Given-When-Then, using technical terms in business scenarios. According to BDD Academy (2024), teams need an average of 4–6 sprints to achieve maturity in writing BDD scenarios.