Behaviour Driven Development — 3/3 — automation

Reader’s guide

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 ./features:

Step 3: Generate the glue code

Simply run 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.

./src/test/java/cucumber/stepdefs/ :

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.

Living Documentation

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.




Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Kong To

Kong To

Developer, Coder or Craftsman, but code quality matters. Technical writer @wesquad @wemanity