Everything we have done until now is related to techniques that can be applied only by developers, for developers. Customers, business representatives, and other parties that are not capable of reading and understanding code were not involved in the process.

TDD can be much more than what we have done up to now. We can define requirements, discuss them with the client, and get agreement as to what should be developed. We can use those same requirements and make them executable so that they drive and validate our development. We can use ubiquitous language to write acceptance criteria. All this, and more, is accomplished with a flavor of TDD called behavior-driven development (BDD).

We'll develop a book store application using a BDD approach. We'll define acceptance criteria in English, make the implementation of each feature separately, confirm that it is working correctly by running BDD scenarios and, if required, refactor the code to accomplish the desired level of quality. The process still follows the Red-Green-Refactor that is the essence of TDD. The major difference is the definition level. While, until this moment, we have been mostly working at the units level, this time we'll move a bit higher and apply TDD through functional and integration tests.

Our frameworks of choice will be JBehave and Selenide.

The following topics will be covered in this chapter:

• The different types of specifications
• Behavior-driven development (BDD)
• The book store BDD story
• JBehave