Behavior Driven Development with JUnit 5. Part 1

Behavior Driven Development with JUnit 5. Part 1

Abstract: In this article, we will show how to develop safe, flexible applications using behavior-driven development (BDD). BDD is a software development technique that starts from the business requirements and goals and transforms them into working features. BDD encourages teams to interact, use concrete examples to communicate how the application must behave, and deliver software that matters, supporting cooperation between stakeholders. Test Drive Development (TDD) helps us build software that works; BDD helps us build software that provides business value. Using BDD, we determine which features the organization really needs and focus on implementing them.

 

Communication problems at the level of a project

 

Communication between people involved in the same project may lead to problems and misunderstandings. Usually, the flow works this way:

 

  1. The customer communicates to the business analyst their understanding of the functionality of a feature.
  2. The business analyst builds the requirements for the developer, describing the way the software must work.
  3. The developer creates the code based on the requirements and writes unit tests to implement the new feature.
  4. The tester creates the test cases based on the requirements and uses them to verify the way the new feature works.

 

But it is possible that the information may be misunderstood, modified, or ignored—and thus the new feature may not do exactly what was initially expected. We’ll analyze how things are going when a new feature is introduced.

 

Behavior Driven Development with JUnit 5. Part 1.jpg

 

Introducing a new feature

 

The business analyst talks with the customer to decide what software features will be able to address the business goals. These features are general requirements, like “Allow the traveler to choose the shortest way to the destination” and “Allow the traveler to choose the cheapest way to the destination.”

 

These features need to be broken into stories. The stories might look like “Find the route between source and destination with the smallest number of flight changes” or “Find the quickest route between source and destination.”

 

Stories are defined through concrete examples. These examples become the acceptance criteria for a story. Acceptance criteria are expressed BDD style through the keywords Given, When, and Then.

 

As an example, we may present the following acceptance criteria:

Given the flights operated by company X

When I want to find the quickest route from Bucharest to New York on

May 15 20...

Then I will be provided the route Bucharest—Frankfurt—New York,

with a duration of...

 

Interested in JUnit?

Check out our trainings

Tudose, Florin-Catalin , Java Champion; Java Chapter Lead; Author at Pluralsight and Manning

Tudose, Florin-Catalin Tudose author linkedin

Java Champion; Java Chapter Lead; Author at Pluralsight and Manning

Tudose, Florin-Catalin , Java Champion; Java Chapter Lead; Author at Pluralsight and Manning

Tudose, Florin-Catalin Tudose author linkedin

Java Champion; Java Chapter Lead; Author at Pluralsight and Manning