Behavior Driven Development with JUnit 5. Part 1
Communication problems at the level of a projectCommunication between people involved in the same project may lead to problems and misunderstandings. Usually, the flow works this way:
- The customer communicates to the business analyst their understanding of the functionality of a feature.
- The business analyst builds the requirements for the developer, describing the way the software must work.
- The developer creates the code based on the requirements and writes unit tests to implement the new feature.
- 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.
Introducing a new featureThe 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.
Java and Web Technologies Expert