Behavior Driven Development: Turning Conversations Into Executable Tests

TL;DR

• Behavior driven development is a collaboration practice where product, development, and testing agree on concrete examples of system behavior before code gets written.
• The examples become Given-When-Then scenarios that run as automated tests, so the specification and the test suite stay the same artifact.
• Behavior driven development runs in three phases: discovery through structured conversation, formulation into readable scenarios, and automation against the application.
• Autosana executes plain-language flows on real iOS, Android, and web devices, which removes the glue-code layer that makes most behavior driven development projects stall.

A story says customers receive a discount on orders over 5000 rupees. A developer applies it at exactly 5000. The product manager meant above 5000. A tester writes a case for 6000, and both implementations pass it.

The defect ships, and the argument happens in production. Behavior driven development exists to force that boundary question into the open before anyone writes code, by insisting the team agree on concrete examples rather than a sentence.

This guide covers the three phases of behavior driven development, how to run the conversation that produces good examples, what changes for mobile, and where adoption usually goes wrong.

What Behavior Driven Development Is

Behavior driven development is a practice where the people who want a feature, the people who build it, and the people who test it agree on specific examples of how the system should behave. Those examples then become automated tests.

The Agile Alliance describes it as an extension of test driven development that shifts the unit of discussion from code behavior to system behavior, in language the business recognizes.

The practical output is a set of scenarios written in a structured natural language format. Each scenario names a starting state, an action, and an expected outcome. Dan North coined the approach, and Martin Fowler's Given-When-Then article remains the clearest description of the format.

Applied to the opening example, behavior driven development produces two scenarios rather than one sentence: an order of exactly 5000 receiving no discount, and an order of 5001 receiving one. The boundary becomes explicit because someone has to write the number down.

Behavior Driven Development vs TDD

The two are compatible rather than competing. A common arrangement drives the outer loop with behavior driven development scenarios and the inner loop with TDD, so a failing scenario leads to a failing unit test which leads to code.

The distinction that matters in practice: a TDD test fails when you refactor, and a behavior driven development scenario survives refactoring because it describes what the user experiences.

The Three Phases

Behavior driven development runs as discovery, then formulation, then automation. Teams that skip straight to automation end up with Gherkin-flavored test scripts and forfeit the benefit.

Discovery is a conversation producing concrete examples. Formulation turns agreed examples into readable scenarios. Automation binds those scenarios to the application so they execute.

The Cucumber documentation treats discovery as the phase carrying most of the value, since the defects prevented there cost zero to fix.

Running Discovery That Produces Real Examples

The common format is a structured session sometimes called example mapping, involving a product representative, a developer, and a tester. Thirty minutes per story is typical.

Work through four artifact types. The story sits at the top. Rules beneath it express business constraints. Examples beneath each rule make the rule concrete. Questions capture anything the group cannot answer, which become follow-ups rather than assumptions.

For the discount story, the rule reads: orders above 5000 receive a 10 percent discount. Examples then pin the boundaries at 4999, 5000, and 5001. A question surfaces immediately: does the threshold apply before or after tax? That question is the entire value of the session, and it costs thirty seconds to ask.

Two signals indicate a session is working. Questions appear, meaning ambiguity is surfacing. Examples cluster around boundaries and error paths rather than the obvious success case.

Formulation: Writing Scenarios People Review

A scenario has three parts. Given establishes state. When performs an action. Then asserts an observable outcome.

Given a cart containing items totalling 5001 rupees When the customer proceeds to checkout Then a 10 percent discount is applied And the order total shows 4500.90 rupees

Four habits separate scenarios that survive from scenarios that rot.

Write in the language of the business, using words the product manager already uses. Terms borrowed from the codebase push the scenario out of reach for the people meant to review it.

Assert outcomes visible to a user. A scenario asserting a database row was written has drifted into unit test territory.

Keep one behavior per scenario. Several When steps in sequence usually means two scenarios wearing one title.

State data explicitly. A scenario saying a large order forces the reader to guess, which reintroduces the ambiguity the practice exists to remove.

Living Documentation

The scenarios execute, so they stay accurate. That property is what separates behavior driven development from a specification document that drifts from the code within a sprint.

When a scenario fails, one of two things happened: the code broke, or the requirement changed and the scenario needs updating. Both outcomes are useful, and both get noticed the same day.

Over time the scenario set becomes the answer to how the system behaves today. New engineers read it to understand the product. Support teams check it before escalating. A compliance reviewer reads it without needing a developer to translate.

Teams running regression testing from behavior driven development scenarios get this property automatically, since the regression suite and the specification are the same files.

Behavior Driven Development for Mobile

Mobile shifts the emphasis in three ways.

Device and OS conditions belong in the Given step. A scenario for a permission flow reads differently on Android 13 than on Android 12, and stating the OS version makes the scenario runnable rather than approximate.

Interrupt behavior deserves its own scenarios. Incoming calls, backgrounding, low memory termination, and connectivity loss mid-action are all user-visible behaviors, which makes them behavior driven development material.

The device matrix multiplies each scenario. One scenario running across six configurations is six executions, so the automation layer has to make that cheap or the scenario count gets cut. Mobile app testing with behavior driven development works when one scenario definition covers the matrix.

Mobile test automation that binds scenarios to element selectors struggles here, because selectors vary across vendor OS forks while the described behavior stays identical.

Behavior Driven Development in CI/CD

Scenarios earn their keep when they run continuously rather than before release.

A workable arrangement tiers them by cost. Fast scenarios covering business rules and API behavior run on every commit. Full user journey scenarios run on every pull request. The complete set across the device matrix runs nightly.

Route results to the people who wrote the scenarios. A product manager who agreed the discount boundary should see when that boundary breaks, and a pull request comment reaches them where a CI log fails to.

Teams running end-to-end suites usually find their existing flows map onto scenarios with modest rewording, which makes adoption incremental rather than a rebuild.

Where Adoption Goes Wrong

Four failure modes account for most abandoned behavior driven development efforts.

Developers write the scenarios alone. The output is a test suite with extra syntax, and the collaboration that creates the value gets skipped. Discovery requires the product representative in the room.

Step definitions multiply. Each scenario phrased slightly differently spawns another glue function, and the maintenance cost eventually exceeds the benefit. Agreeing a shared vocabulary early keeps this contained.

Scenarios describe clicks instead of behavior. A scenario reading when the user taps the button with ID checkout-submit has become a test script, and the business reader is gone.

Scenario counts grow without pruning. Every requirement change should retire the scenarios it invalidates, and teams rarely schedule that work.

How Autosana Fits

We built Autosana around the phase where behavior driven development usually stalls, which is automation.

Our flows are written in plain language describing user intent. A scenario step saying the customer proceeds to checkout runs directly, with no step definition layer between the sentence and the execution.

That removes the glue-code maintenance that ends most behavior driven development projects. Our guide to writing effective flow instructions covers phrasing that executes reliably.

We run one flow definition across real iOS, Android, and web devices, so a scenario costs the same whether it covers one configuration or eight. That keeps mobile scenario counts from being cut for budget reasons.

We organize flows into suites matching the tiering above, triggered through CI/CD integration and automations. Results arrive with video, so a failing scenario shows the product manager exactly what the user would have seen.

Conclusion

Take the next story your team picks up and run a thirty-minute discovery session on it. Write the rules, write examples at the boundaries, and write down every question the group cannot answer.

Count the questions. That number is how many production arguments the session just prevented, and it is usually higher than anyone expects on a story that looked clear.

Then write the examples as scenarios and make them run. The rest of behavior driven development follows from those two steps.

FAQ

What is behavior driven development?

Behavior driven development is a practice where product, development, and testing agree on concrete examples of system behavior before implementation. Those examples become Given-When-Then scenarios that run as automated tests.

How does behavior driven development differ from TDD?

TDD drives design at the function level in code, written by developers. Behavior driven development describes user-visible behavior in business language, written collaboratively. A common arrangement runs behavior driven development as the outer loop and TDD as the inner loop.

What are the three phases of behavior driven development?

Discovery, where the team produces concrete examples through structured conversation. Formulation, where agreed examples become readable scenarios. Automation, where scenarios get bound to the application and execute.

What does a Given-When-Then scenario look like?

Given establishes starting state, When performs a single action, and Then asserts an observable outcome. Data appears as explicit values rather than descriptions, so the scenario is runnable as written.

Is Cucumber required for behavior driven development?

Cucumber is one common tool, alongside SpecFlow, Behave, and JBehave. The practice depends on the collaborative conversation rather than any framework, and teams can run scenarios through other execution layers.

How does behavior driven development work for mobile apps?

Device and OS conditions go into the Given step, interrupt behaviors get their own scenarios, and one scenario runs across the device matrix. Selector-bound automation struggles because vendor OS forks change elements while behavior stays constant.

Why do behavior driven development projects fail?

Developers write scenarios alone so collaboration gets skipped, step definitions multiply until maintenance outweighs value, scenarios describe clicks instead of behavior, and obsolete scenarios accumulate without pruning.

What is living documentation?

Scenarios that execute against the running system, so they stay accurate. When one fails, either the code broke or the requirement changed, and both get noticed the same day rather than months later.