The following is a chapter summary for “BDD Books – Discovery” by Gaspar Nagy and Seb Rose for an online book club.
The book club is a weekly lunchtime meeting of technology professionals. As a group, the book club selects, reads, and discuss books related to our profession. Participants are uplifted via group discussion of foundational principles & novel innovations. Attendees do not need to read the book to participate.
Background on BDD Discovery
DISCOVERY
“Explore behavior using examples
Written by the creator of SpecFlow and the author of The Cucumber for Java Book, this book provides inside information on how to get the most out of the discovery phase of Behaviour Driven Development (BDD). This practical guide demonstrates good collaboration techniques, illustrated by concrete examples.
This book is written for everyone involved in the specification and delivery of software (including product owners, business analysts, developers, and testers). The book starts by explaining the reasons BDD exists in the first place and describes techniques for getting the most out of collaboration between business and delivery team members.
This is the first in the BDD Books series that will guide you through the entire development process, including specific technical practices needed to successfully drive development using collaboratively-authored specifications and living documentation.”
BDD Discovery
Chapter 1
Behavior Driven Development (BDD) is an agile approach to delivering software.
BDD is about collaboration and domain discovery.
JUnit requires developers to use the word “test” in their method names, which emphasizes testing over documentation, design, and definition of the expected behavior.
Dan North originally designed BDD as a set of practical rules for naming and structuring tests to preserve a connection to the requirements. The business-readable format was designed so the business representatives could confirm the expected behavior.
1.1 The Missing Link
The purpose of software development is to deliver solutions to business problems.
A continuing challenge is to verify that the software actually satisfies the requirements.
Waterfall methods have slow feedback cycles, which allows projects to go off track. In response, the industry began to experiment with methodologies like XP and frameworks like Scrum.
Please refer to Figure 1
BDD helps maintain a connection between the requirements and the software – and as such acts as a bridge. The bridge is made out of examples. Every test is an example. Each example is an expression of a required system behavior.
“If you have sufficient examples you define the behavior of the system – you have documented the requirements. Business people remain engaged, because the examples are expressed in business language. Fast feedback is preserved, because the examples are automated.”
Chapter 1 – The Missing Link
Chris Matts is originally credited with Given, When, Then keyword format for examples written as Scenarios. There are several free tools for writing BDD Scenarios: Specflow and Cucumber.
1.2 How Does BDD Work?
“Examples (and their formalized representation – scenarios) play a critically important role in BDD. To understand how BDD works, let’s have a look at the way that these scenarios are created and how they drive the development process.”
Chapter 1 – How does BDD Work?
BDD is used when the details of user stories are discussed, in the form of examples. Focusing on examples makes the business rules clear. As a general guideline, each business rule should be illustrated by one or more examples.
“Examples also enable us to explore our understanding of a rule. Exploration often leads to the discovery of complexities and assumptions that otherwise would not be found until much later in the development process.”
Chapter 1 – How Does BDD Work?
Examples:
- Examples can take various forms: input-output data pairs, sketches of the user interface, bulleted lists of different steps of a user workflow or even an Excel workbook illustrating a calculation or a report.
- All examples describe a behavior as a combination of context, action, and outcome.
Some examples are formulated into scenarios when a user story is ready. BDD tools turn these scenarios into executable tests before the related behavior has been implemented in the application itself.
Test-Driven Development (TDD) helps speed up the feedback loop by demanding that teams write automated tests before they write the code. A test is written first, which initially fails. Next, the application feature is implemented so that the test passes. After code cleanup (refactoring), the next test can be written.
BDD drives development in a similar fashion to TDD, however the scenarios are described from the perspective of the user. Begin by writing a scenario that should fail. Next, write the automation & application code until the scenario passes. After code cleanup (refactoring), the next scenario can be written. BDD does not replace TDD, but rather is built into the red-green-refactor cycle.
Please refer to Figures 3 and 4
BDD Feedback Benefits:
- Implementation correctness for developers
- Overall solution for the product owner
- Implemented behavior to help business analysts understand existing functionality
- Provides a signal for manual / exploratory testers that a feature is ready for testing
- Safety net for developers, identifying unwanted side effects of changes
- Detailed documentation of application behavior for any support team
- Defines a domain language that is understood by everyone
1.3 What About Testing?
BDD does not replace classic testing or testing skills. BDD does not define how testing should be performed, but rather provides guidelines about the Agile Testing Process.
The focus of the Agile Testing Process is to help ensure defects are never added to the codebase in the first place. Testers are involved in project requirement discussions, to help prevent bugs.
A significant proportion of defects are rooted in problems that arise from misunderstood requirements (see in Outside Resources for J.-C. Chen and S.-J. Huang, 2009). The primary type of verification is done through exploratory testing (see in Outside Resources for E. Hendrickson, 2013).
1.4 A Language That is Understood by Everyone
Every project is a voyage of discovery. A language must be established in which the customer can explain the problem(s) in detail and the development team can explain the solution. Teams should write scenarios using this language. If scenarios drive the implementation, then the solution will be close to the business domain.
1.5 Living Documentation
Living Documentation is a form of documentation that represents the current state of the application, which is updated in real-time. Scenarios make up the living documentation, which should be understandable by everyone. Scenarios should be written in domain-specific terms to describe the behavior of the application.
1.6 What is BDD, Then?
BDD is an agile approach that consists of three practices that have to be addressed in order:
- “The first practice is discovery, a structured, collaborative activity that uses concrete examples to uncover the ambiguities and misunderstandings that traditionally derail software projects.”
- “The second practice is formulation, a creative process that turns the concrete examples produced during discovery into business-readable scenarios.”
- “The third, and final, practice is automation where code is written that turns the scenarios into tests.”
- The above practices must be adopted in order to gain the expected benefits.
The benefits of automation:
- “When the tests pass, the development team can be confident they have delivered what the business have asked for.”
- “The tests give the development team a safety net when the time comes to modify the code.”
- “The tests form living documentation of how the system behaves, readable by the business, guaranteed to be up-to-date.”
Please refer to Figure 5
1.7 What We Just Learned
BDD was created to address the challenges associated with misunderstandings in a project team. Examples make an excellent bridge between business requirements and technical specifications.
Scenarios written in a ubiquitous language, act as both documentation and tests. As documentation, they close the gap between business and development. As tests, they demonstrate the solution being implemented aligns with business requirements. The Scenarios provide documentation that describe the actual application functionality.
The focus of BDD is collaboration and the examples are turned into test cases. The purpose is to inform all involved that development is moving in the correct direction.
