In this chapter, we focus on an important part of BDD that you need to understand if you’re to get the most out of whatever BDD strategy you adopt. You’ve seen how BDD encourages teams to express requirements in terms of executable specifications that can be run in the form of automated tests. These executable specifications become the definitive reference (often referred to as the “source of truth”) for the current set of application requirements. The definitive form of these executable specifications is generally source code, so they fit neatly into the overall development process and drive the automated tests. The reports generated by the automated tests refer to the original executable specifications. These reports, which combine the original specifications, acceptance criteria, and test results, are what we call living documentation.
Living documentation is a key part of the BDD process. Business stakeholders can use it to review what a feature does and confirm that it corresponds to business needs and constraints. Testers can use it as a starting point for exploratory testing, saving time in routine manual testing of basic features. And developers can use it to understand what an existing feature does and how it works.