I keep hearing the same concern: “We don’t practice BDD because we don’t know how to automate Given/When/Then statements.”
This stops teams before they even start. They see BDD as a testing framework first, and when they can’t figure out the automation piece, they skip the entire practice. Including the conversations.
That’s backwards.
The Conversation Comes First
BDD isn’t about automation. It’s about clarity.
The Given/When/Then format is a thinking tool. It helps us understand what we’re building before we build it. It surfaces assumptions. It reveals edge cases. It forces us to be specific about scenarios instead of vague about features.
You don’t need to know how to automate anything to have these conversations.
Even working alone, you can write Given/When/Then statements. You’re clarifying for yourself: What are the different pieces that go into this feature? What are the scenarios? What are the edges of the problem I’m trying to solve?
When you’re working with a team, these statements become the structure for the conversation. They help everyone aim at the same target. They create shared understanding.
None of this requires automation.
Automation Is a Separate Decision
Once you have clarity—once you’ve had the conversations and written the scenarios—then you can ask: Where would it be most valuable to automate these?
This is a different question with different considerations:
-
Where is automation cheapest to write and maintain?
-
Where will it run fastest?
-
Where does it give us the most confidence?
One story with several Given/When/Then scenarios might be automated in multiple places:
-
Some scenarios as end-to-end tests
-
Others as front-end component tests
-
Others as API tests
-
Still others as back-end integration or unit tests
You’re not trying to automate everything everywhere. You’re making strategic choices about coverage.
An Example: Business Rule Validations
Say you have a feature with multiple business rule validations. You could write end-to-end tests for every validation scenario. But end-to-end tests are slow. They’re expensive to maintain. They’re brittle.
Instead, you might:
-
Write the detailed validation scenarios as back-end unit tests (fast, cheap, focused)
-
Write a few integration tests to confirm database access works as expected
-
Write API tests to verify the endpoints behave correctly
-
Write just enough front-end and end-to-end tests to confirm the feature is wired up
You get full feature coverage. You get refined scenarios automated where they’re most valuable. And you’ve optimized for both the cost of writing tests and the speed of running them.
But none of this happens if you don’t have the conversations first.
Start With Understanding
The automation question can wait. Start with the scenarios. Start with the conversations. Start with clarity.
Write the Given/When/Thens. Think through the edges. Surface the assumptions. Get everyone aligned on what “done” looks like.
Then, as a separate step, decide where and how to automate.
BDD is a conversation practice that happens to produce automatable scenarios. Not the other way around.
Leave a Reply