- It is a way of driving a (software) product forward
- It is often associated with Given/When/Then scenarios (aka Cucumber/Gherkin)
- It is about writing down what you want before you build it. In a way that everyone can understand
- Avoid building the wrong thing or wasting time
- Foster better understanding of the product
- Lack of communication around features
The bigest issue is communication and shared understating.
- Use BDD as a way of deliberately discovering features
- Use Given/When/Then scenarios to verify that the scenarios are understood
As a product grows it becomes harder to "hold it in your head".
- Using cucumber scenarios as a way of capturing and documenting your product
- Establishing source-of-truth for terms and idioms used to communicate your product features
This is the heart of BDD. By writing down what you want in a clear manner you're letting that drive the product and not the other way around.
Avoid getting stuck on questions that can't be answered by this small team
Using BDD scenarios to automate testing of your product and keep it and the product honest.
- How Example Mapping can be used to capture stories
- What Cucumber and Gherkin are
- Who and How to write Given/When/Then scenarios
- A quick mention about automation
- Gherkin is a syntax for writing Given/When/Then scenarios.
- Cucumber is a set of tools and frameworks to automate testing of user stories
# -- FILE: features/gherkin.rule_example.feature
Feature: Highlander
Rule: There can be only One
Example: Only One -- More than one alive
Given there are 3 ninjas
And there are more than one ninja alive
When 2 ninjas meet, they will fight
Then one ninja dies (but not me)
And there is one ninja less alive
Example: Only One -- One alive
Given there is only 1 ninja alive
Then he (or she) will live forever ;-)
Rule: There can be Two (in some cases)
Example: Two -- Dead and Reborn as Phoenix
...- Use Example Mapping as a starting point
- Get the folks who'll build/test the feature to write out more concrete scenarios
- Verify that those scenarios match product/stakeholder understanding.
- Use cucumber tooling to generate stubs and tests based on Gherkin
- Consistency in Gherkin makes for re-useable tests
- Use them for your Domain Model, drive a browser or control hardware!
- Gherkin syntax should only change when your product's feature changes
- Test implementation can change whenever.
// features/support/steps.js
const { Given, When, Then } = require("cucumber");
const { expect } = require("chai");
Given("a variable set to {int}", function(number) {
this.setTo(number);
});
When("I increment the variable by {int}", function(number) {
this.incrementBy(number);
});
Then("the variable should contain {int}", function(number) {
expect(this.variable).to.eql(number);
});- "It'll take me longer!"
- "I don't want to learn something new (or my Boss won't give me the time)!"
- "Does this mean more meetings? I hate meetings!"
- "We have an old codebase, we're not spring chickens!"
- Writing the BDDs after building. This defeats all the collaboration/shared understanding gains.
For some more info