This is a crash course to BDD and Cucumber based on my own experiences and opinions.
Behavior-driven development (BDD) is a software development process based on TDD with influences from Domain-driven design (DDD). BDD is used to provide a tool for collaboration between development and business teams. BDD is also a way to combine unit and acceptance testing into one and also relates to the agile practice of writing user stories by providing a way to define acceptance criteria.
Cucumber is a software tool used to execute BDD specifications. To do this it uses Gherkin as formal description language. Gherkin defines a number of different artifacts. For instance:
Given
,When
,Then
keywords for specifying a prerequisite, an user action and an expected resultScenario
A set ofGiven
,When
,Then
that forms a user scenarioExamples
- A set of example values used in aScenario
Feature
- A collection ofScenario
:s related to aFeature
This is an example of a Gherkin feature file:
Feature: Elevator
Scenario Outline: Calling the elevator when it's on the entrance floor
Given The elevator is on the entrance floor
When the elevator is called from the <call> floor
Then the elevator is moved to the <destination> floor
Examples: Floors
| call | destination |
| 1 | 1 |
| 2 | 2 |
- Install Git, JDK, Gradle, clone the repo and then run
gradle test
- Read more about Cucumber JVM
- You could also head to the SoapUI repo and have a look at how I implemented Cucumber JVM there.
- Have fun!
- Great for collaboration between different rolls such as programmers, testers, designers and product owners / domain experts
- Provides a natural and collaborate way to write acceptance criteria up front
- Specifications == tests
- Like with TDD, it encourage testing upfront and could be a good way to involve testers early
- Non-programming roles can write tests
- Manual and automated tests follows the same structure (you select which scenarios to run automatically)
- Test results are very clear and understandable
- Works very well with integration and GUI tests
- Using StepDefs the speficications becomes reusable and modular
- Could be just a overhead to writing plain unit/integration tests
- A scenario always have certain degree of subjectivity and could lead to debates and misunderstandings
- Hard to know at which level the scenarios should be written
- Too low level requires a lot of maintenance and lengthy descriptions
- Too high level makes it hard to interpret the results
- Often not suitible for pure integration tests
- Who's responsible to maintaining the features? Who have the time?
- Who's looking at the results?