Bob was sitting desperately in front of a bunch of failing JUnit tests intended to verify the part of the application he just refactored.
The one who wrote them - to be honest it could have been any of us at a certain stage of our life - had the idea that JUnit is
somewhat different from production Java:
there is no need for code conventions, clean code, comments or whatever that could make the maintainer’s life easier.
Well, Bob spending the past twenty minutes of his life reverse engineering the code, silently looked around,
realised that nobody is watching him and put a sad @Ignore annotation before a test.
He was thinking about removing the tests, but he just didn’t want to hurt the inner feelings of any fellow developer.
BDD is here to help
Behaviour Driven Development was introduced by Dan North back in 2003.
BDD focuses on obtaining a clear understanding of desired software behavior through writing test cases in a natural language
that non-programmers can read:
Given some initial context,
When an event occurs,
Then ensure some outcomes.
It proved to be really useful in the following topics:
test definitions can serve as functional documentations
writing test first is easier
better APIs come from writing testable code
help maintainers understand the intention behind the code
defining test steps involves having fewer parts to change (low duplication)
In the integration tests it needs to be verified that all of the code works correctly,
all of the combined code units work well in their environment and the module is ready to be integrated
with external systems and resources.
The external connections should be mocked for these tests to cut the dependencies and to avoid side effects of the tests.
I reuse the component structure from the previous post and mark the mocked components with orange:
Defining a REST API as application interface is what everybody is doing nowadays, it comes with certain benefits:
simplifies a very complex functionality around resources
reduces client server coupling
provides stateless communication
is easy to use / implement
As the provided REST interface will be the one which determines the behaviour of the application towards a consumer.
So why not BDD it?
Example in book inventory app
For my example book inventory app I implemented automatic behaviour driven tests
to verify the REST APIs in a full application context embedded into Spring’s
I set up a full application context but mocked the RestTemplate to cut external service calls and used an in memory (hsql) db.
Under the hood Cucumber library provides the framework for defining the expected behaviour.
The testcases are using Cucumber’s plain text DSL:
Gherkin and defining given-when-then steps for the scenarios.
Gherkin is a business readable, Domain Specfic DSL that lets you describe software's behaviour without detailing how that behaviour is implemented.
The REST API tests are located under src/test/rest/resources/bookinventory/integration folder as .feature files.
Running them are part of the JUnit execution that is hooked by BookInventoryIntegrationTest.java
to execute all the features annotated with @restApiIntegration.
Common step definitions are defined to verify the REST calls in CommonRestCallStepDefs.java.
The testcases for the book inventory resource are defined in the BookInventoryIntegrationTest.feature file.
Test: Create a book
Test: Find a book by isbn
Test: Find a book by a not existing isbn
Test: Find a book by author
Test: Find a book by title
Test: Find all books
Test: Create a book
Behaviour driven integration testing of the REST API helps in rapid application development, facilitates test driven and
contract first interface design. Using the described approach makes it really quick to verify the REST endpoints and application context set up.