To undersant the story lets use some simple example: the comapny maintains a policy regarding adding and removing a passanger to a flight. The flights may be a few types:
other added at the later time
If the flight is an economy one, most VIP passangers and usual ones may be added to it. If the flight ia s business one, only VIP passangers may be added to it.
Adding Passanger Business Logic
Removing passanger business logic
And there is also a policy for removing a passanger from the flight. It also involves answering to yes/no questions. A usual passanger may be removed from a flight, a VIP passenger cannot be removed.
Removing Passenger Business Logic
Usual passenger can be remove fron a flight, a VIP passenger cannot be removed. As we can see from these two activity diagrams, the inital business logic focus on decision making.
Below is a the simple class of the application. The flight class has two sub-classes: EconomyFlight and: BusinessFlight. The police of adding a passannger and removing a passenger are encapsulated into: addPassenger and: removePassanger methods. As these methos are inheruted from the Flight class and are at the level of each sublcass, we may say that the decision of each policy to apply will be preactically made at runtime through polymorphism.
Initial Application Design
From TDD to the BDD
Below are test that have been build as TDD. We have here 4 tests. From theit names, we understand that we have two flights, economy and business and two passangers: usual and VIP. We are doing some operations with this pairs.
This tests are good but:
they do not discuss which the expectations are, which makes them harder to understand and to fix if they break
they do not seem much about what they are actually tesing
To change to better we can adopt some conventions:
use JUnit5 features more effectively
use nestet tests
reduce code application by reinitialize object before each test
attach to test lables to replace the long names to express in plain English what we are doing
Below is simple test written in new way:
This is a first step from TDD to the BDD application, introducing methods with significant names using nested tests and annotating them. This way helps us to claryfy tests but we use only JUnit5 and it’s annotations. This is not full BDD and to use full features ofd BDD we will switch to the special frameworks.