Behaviour Driven Development — 3/3 — automation
This article is part of a serie:
From a user story acceptance criteria to living documentation
BDD Automation Step
Adding up the
automation step, where we drive the development of each work item by using the scenarios written in acceptance criteria, we are optimising our work on delivering focused and expected values.
So we have these things as a bonus by the way :
- having automated tests (unit and functional)
- having a living documentation
- favouring design driven and test driven development
- good code coverage
Automation with Cucumber and Spring
Step 1: Bootstrap a spring application with cucumber
You may refer to this repository bootstrap-spring-cucumber-java to bootstrap an application.
Step 2: Add a scenario
Create a withdrawal feature file under
Step 3: Generate the glue code
mvn clean verify`:
This will generate the glue code in the console:
Step 4: Add the glue code to the Step Definitions class
Copy/paste the glue code to the step definitions in the following class.
Step 5: Implement every step definition (failing scenario)
Step 6: Implement business code (passing scenario)
Here we can loop with TDD to cover happy unit test cases, unhappy unit test cases, and corner cases, even extreme test cases. Here we still need to keep focus on the scenario. All corner and extreme test cases must be surrounding that specific scenario. Once all unit tests passed, we can make the scenario pass. Then we can continue with another scenario.
Once the business code is implemented to satisfy the business requirement, simply run this command
mvn clean verify` again to execute again the tests.
Now a report is generated under ./target/cucumber/cucumber-html-reports/overview-features.html. Open it with a browser to see the results and you should see this:
That is what we call a living documentation. The approach “Specification by examples” aims to describe business requirement using concrete examples. And it comes with a living documentation as a result, examples of behaviour becomes the documentation per se. They are also promoted into automated tests. Whenever a test fails, it indicates that the documentation is no longer in sync with the code so it must be fixed as soon as possible. If the documentation has to evolve because the business changes then the code will evolves too, as they are glued together.