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:

• economy
• 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.

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.

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.