Spring Builders: Marcus Keenton

How to implement behavior driven development: a step-by-step guide for Agile teams

Marcus Keenton — Thu, 01 Oct 2026 04:54:46 +0000

Adopting behavior driven development (BDD) sounds simple on paper. Write scenarios in plain language, automate them, and ship software everyone agreed on. In practice, many teams install Cucumber, write a few feature files, and quietly give up three sprints later.

The problem is rarely the tooling. It is the rollout. BDD changes how product owners, developers and testers work together, and that change needs a plan.

This guide walks through how to introduce BDD to an Agile team one step at a time. If you are new to the concepts, Gherkin syntax or the tools involved, read this overview of the behavior driven development framework first, then come back here to put it into practice.

Step 1: start with one team and one feature

Do not roll BDD out across the whole organization at once. Pick one team, ideally one with an engaged product owner, and one upcoming feature with clear business rules.

Good first candidates include:

Checkout or payment flows, where rules about totals, discounts and failures are easy to express as examples.
Account and login features, where success and failure cases are well understood.
Pricing or eligibility logic, where the business already thinks in "if this, then that" terms.

Avoid starting with infrastructure work, internal libraries or prototypes. They have little business-facing behavior, so BDD adds overhead without much payoff.

Step 2: write the user story the BDD way

Every BDD cycle begins with a user story in the familiar format:

As a returning customer
I want to apply a discount code at checkout
So that I pay the promotional price

The "so that" line matters more than it looks. It tells the team why the feature exists, which helps everyone judge edge cases later. If nobody can fill it in, the story is not ready.

Step 3: run your first Three Amigos session

Bring together three perspectives: business (a product owner or analyst), development and testing. Spend 25 to 30 minutes on the story using example mapping.

Put the story on one card at the top.
Write each business rule on its own card underneath.
Add at least one concrete example under every rule.
Park anything nobody can answer on a separate question card.

For the discount code story, the rules might look like this:

A valid code reduces the order total by its percentage.
An expired code is rejected with a clear message.
Only one code can be applied per order.
Codes cannot reduce the total below zero.

Each rule now has examples the whole team agreed on, before a single line of code exists. That alone prevents most of the rework BDD is known for removing.

Step 4: formulate the examples as Gherkin scenarios

After the session, a developer or tester turns the examples into a .feature file. Keep the steps declarative, describing what happens rather than which buttons get clicked.

Feature: Discount codes at checkout
  As a returning customer
  I want to apply a discount code at checkout
  So that I pay the promotional price

  Background:
    Given a cart with a subtotal of 100.00

  Scenario: Valid code reduces the total
    When the customer applies the code "SAVE20"
    Then the order total should be 80.00

  Scenario: Expired code is rejected
    When the customer applies the code "SUMMER23"
    Then the customer should see the error "This code has expired"
    And the order total should be 100.00

  Scenario: Only one code per order
    Given the code "SAVE20" is already applied
    When the customer applies the code "WELCOME10"
    Then the customer should see the error "Only one code can be used per order"

Share the file with the product owner before automating it. If they cannot read it and confirm it matches the conversation, rewrite it until they can.

Step 5: automate the scenarios

Developers now write step definitions that connect each Gherkin step to code. The usual flow follows a red, green, refactor rhythm:

Run the scenario and watch it fail, because the feature does not exist yet.
Write just enough application code to make it pass.
Refactor the code and the steps while the scenario stays green.

Where possible, automate at the API level rather than through the browser. API scenarios run faster, fail less often for unrelated reasons, and test the same business rules. Save browser automation for a small set of critical end-to-end journeys.

Step 6: run scenarios in CI and treat them as documentation

Add the BDD suite to your CI pipeline so it runs on every build. Use tags to keep feedback fast:

@smoke scenarios on every commit
@regression scenarios on every merge to the main branch
The full suite before each release

When a business rule changes, update the scenario first, then the code. This keeps the feature files accurate, which is what makes them living documentation instead of another stale spec.

Step 7: review, measure and expand

After two or three sprints, hold a short retrospective on the BDD pilot. Useful questions include:

Did the Three Amigos sessions surface issues earlier than before?
Did fewer bugs come back from QA or production for these features?
Can the product owner read and trust the feature files?
Are the scenarios slow, flaky or duplicated anywhere?

If the answers are mostly positive, expand BDD to the next team and share the scenarios you wrote as examples. If not, the most common fix is more business involvement in discovery, not more automation.

Common mistakes to avoid

Skipping discovery. Writing Gherkin without the conversation turns BDD into extra syntax on top of ordinary tests.
Imperative steps. Scenarios full of clicks and field names break with every UI change.
One giant scenario. If a scenario has several When steps, split it into one behavior per scenario.
Trying to cover everything. BDD covers key business behaviors. It does not replace unit, integration or regression tests.

Filling the regression gap BDD leaves behind

BDD is designed to define and verify intended behavior. It is not designed to capture every request, payload and dependency interaction your real users generate in production. Writing scenarios for all of that by hand would make your suite slow and impossible to maintain.

Keploy handles that part for APIs. It records real API traffic and turns it into test cases, with mocks for databases and downstream services, so you get regression coverage based on actual usage without writing test code. Your team keeps BDD for new behavior and lets Keploy protect what already works.

Frequently asked questions

How long does it take to adopt BDD?

Most teams see the benefits of discovery within the first sprint. Getting comfortable writing good scenarios and maintaining an automated suite usually takes two to three months.

Who should write the Gherkin scenarios?

Developers or testers usually write them after the Three Amigos session. The product owner reviews them to confirm they match what was agreed.

Do we need a specific tool to start BDD?

No. You can run discovery sessions with index cards or a whiteboard. Tools like Cucumber, Behave, pytest-bdd or Reqnroll come in when you automate the scenarios.

Can we use BDD and TDD together?

Yes. Many teams use BDD scenarios to define features at the acceptance level and TDD to build the code underneath them.

What if our product owner does not have time for discovery sessions?

Start with short sessions on the highest-risk stories only. If business stakeholders cannot commit any time, BDD will deliver limited value, and that is worth raising early.

Conclusion

Implementing BDD well is mostly about sequence. Start small, have the conversations first, write declarative scenarios, automate them at the API level, and keep them running in CI. Expand only once the pilot team sees fewer misunderstandings and fewer surprises.

Want regression coverage to sit alongside your BDD suite? See how Keploy generates API tests from real traffic.

The Real Cost of a Free API Testing Tool Is Never the License

Marcus Keenton — Tue, 11 Aug 2026 04:39:34 +0000

The Real Cost of a Free API Testing Tool Is Never the License

Free is a powerful word when you are choosing tooling, and API testing has a lot of free options competing for attention. The instinct is to treat free as the obvious win and move on. In practice, the license fee is almost never the real cost of a tool. The real cost is what it does to your time, your test suite, and your team over the next two years, and that cost is invisible on the day you install it.

Free rarely means no cost

Every tool you adopt carries a cost beyond its price tag. Someone has to learn it, integrate it into CI, maintain the tests written in it, and eventually migrate off it if it stops fitting. A free tool with a steep learning curve, thin documentation, and an awkward CI story can easily cost more in engineer hours than a paid one that just works. The money you saved on the license is trivial next to a senior engineer spending afternoons fighting the tool instead of writing tests. Free changes where the cost lands, from a budget line to your team's time, but it does not remove it.

What to actually evaluate

When I look at free api testing tools, the license is the last thing I care about. The first questions are how quickly the team can become productive in it, how cleanly it fits into the pipeline they already run, and how much manual effort it takes to keep tests current as the API changes. A tool that captures real traffic and generates tests earns its keep differently than one that expects every case to be hand authored, and that difference matters far more than whether either one costs money. The right question is not what does it cost, it is what does it demand of us over time.

The maintenance question is the real one

Most of the lifetime cost of any testing tool is maintenance, not setup. A tool that makes writing the first test easy but keeping a hundred tests current painful is a bad deal at any price, free included. This is where a lot of free tools quietly fail. They demo beautifully, you write ten tests in an afternoon, and then six months later those tests are a maintenance burden nobody wants to own because every API change means a manual rewrite. The tools worth using are the ones where the suite stays cheap to maintain as the system evolves, and that property has nothing to do with the price.

Open source is free in a different way

It is worth separating two things people both call free. There is free as in no license fee, and there is open source, which is free in a deeper sense because you can see how it works, extend it, and are not at the mercy of a vendor's roadmap. For infrastructure as central as your testing tooling, that second kind of free carries real weight. An open source tool that fits your workflow gives you control that a closed free tier never will, and it removes the risk of a vendor deciding tomorrow that the feature you depend on now lives behind a paywall. Not all free is equal, and this distinction is often the one that matters most in the long run.

Where the free tier trap hides

The other thing to watch with anything labeled free is what happens at the boundary. A free tier that covers small projects but meters the things you will need at scale, more runs, more environments, team features, is not really a free tool. It is a trial with a generous limit, and the moment you have built your workflow around it, the cost arrives with your negotiating position already weakened. This is not automatically a bad deal, but you should walk in knowing which kind of free you are choosing, because the switching cost once your suite depends on the tool is exactly what that pricing model is counting on.

Where this leaves me

Free is a fine place to start and a terrible place to stop thinking. The tools worth adopting are the ones that stay cheap in the currency that actually matters, which is your team's time, as your test suite grows and your API changes underneath it. Evaluate a free tool exactly as critically as a paid one. Ask how fast people get productive, how it fits your pipeline, how much upkeep it demands, and whether free means genuinely open or just unpriced for now. Answer those honestly and the price tag becomes what it should always have been, the least interesting fact about the tool.

When Generative AI Testing Tools Make Things Worse: An Honest Assessment

Marcus Keenton — Mon, 29 Jun 2026 11:38:17 +0000

The adoption enthusiasm around generative AI testing tools has produced an unusual
amount of uncritical coverage. Every tool in the category is described as
revolutionary, transformative, or at minimum dramatically better than the
alternative. The realistic picture is more nuanced: these tools produce genuine
value in specific contexts and create specific problems in contexts they're not
suited for.

Understanding when generative AI testing tools make things worse is as practically
useful as understanding when they make things better, because adopting a tool in the
wrong context creates technical debt that costs more to unwind than the tool saved
in the first place.

The False Confidence Problem

The most consequential failure mode for generative AI testing tools is generating tests that pass confidently while asserting on incorrect expectations. A language model
that infers the wrong behavior generates tests that validate the wrong thing. The
tests pass, the CI pipeline goes green, and the team gains confidence in an
assertion that was incorrect from the beginning.

This failure mode is worse than having no tests, because no tests produce no
confidence signals and teams compensate by being more careful. False confidence
tests produce incorrect confidence signals that lead teams to be less careful than
the situation warrants. A production incident that follows from this failure is more
damaging than one following from acknowledged coverage gaps.

The Maintenance Illusion

Generative tools that produce test code, rather than tests that run continuously
from recordings, create a maintenance illusion. The tests look like they're being
maintained because new tests are being generated. But the generated tests reflect
the state of the code at generation time. When the code changes, the generated tests
don't automatically update.

Teams that adopt AI testing tools (https://keploy.io/blog/community/ai-testing-tools)
for code generation without building a deliberate review and update process end up
with a growing collection of tests, some current and some stale, with no reliable
way to distinguish between them. The larger the collection gets, the less
trustworthy any individual test becomes.

The Coverage Metric Distortion

Generation tools can produce a large number of tests quickly, which inflates
coverage metrics in ways that don't reflect actual protection. A test suite with a
thousand generated tests covering common patterns has a higher line coverage
percentage than a suite with a hundred carefully written tests covering critical
paths and edge cases, but provides less protection against the failures that
actually matter.

Teams that use coverage percentage as a proxy for test quality get misled by the
volume that generation tools produce. The metric needs to change alongside the
tooling: what matters is not how many tests exist but whether the tests would catch
the failures that would be expensive if they reached production.

When Generation Tools Work Well

The contexts where generative testing tools consistently add value are narrow enough
to be specific: bootstrapping coverage for new features before any real traffic
exists, proposing updates to tests that are known to be stale after an API change,
and analyzing existing test suites to identify coverage gaps that deliberate test
writing should address. In these contexts the tools are collaborators that do the
tedious parts of test work, not replacements for the judgment that determines what's
worth testing.