BDD is not just a test automation practice (Book review: The BDD Books — Discovery)

How many of you can explain what BDD is?

If you were writing Gherkin in cucumber, would it be BDD? Or if you use RSpec to automate your tests, is it BDD? Or is it BDD if you were creating high-level automated tests such as E2E?

If you think that any of them is the true answer, you’d better read the book I’m about to introduce. You are missing an important understanding of BDD.

Typical mistakes are to look at BDD as a tool-thing, or to think of BDD as a mechanical process, such as filling out a Given/When/Then template.

The BDD Books — Discovery

The BDD Books — Discovery was published by Gáspár Nagy and Seb Rose on 2018–02–23.

[embed]The BDD Books - Discovery Written by the creator of SpecFlow and the author of The Cucumber for Java Book, this book will give the reader the…leanpub.com

The BDD Book series consists of three ones, Discovery, Formulation, Automation. The BDD Books — Discovery is the first in them.

This book is referenced within the presentations of BDD practitioners. For example, Riya Dattani and Chris James gave a presentation on Acceptance Tests, BDD & Go at GopherCon UK 2021 and introduced this book.

Discovery, Formulation, and Automation are three practices in BDD.

• Discovery: a structured, collaborative activity that uses concrete examples to uncover ambiguities and misunderstandings
• Formulation: a creative process that turns the concrete examples produced during discovery into business-readable scenarios
• Automation: to turn the scenarios into automated test codes

This book describes the first practice “Discovery”. That’s why the table of contents is as follows.

Chapter 1 — What is BDD? Chapter 2 — Structured conversation Chapter 3 — What is an example? Chapter 4 — Who does what and when Chapter 5 — How to get business involved

In this book review, I will focus on the important points that impressed me and that I would like to examine in more detail.

BDD is a collaborative work

As stated in Manifesto for Agile Software Development, collaboration is an important factor in an agile team.

[embed]Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. These are our values and…agilemanifesto.org

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

And, BDD is an agile approach that insists that detailed requirements for a feature should be defined collaboratively by the business and delivery teams.

When learning about BDD, ATDD, and SBE, many software developers overlook their collaboration aspect. This series “Discovery” focuses on their collaborative practice using concrete examples and leaves the explanations of formalization like how to use Gherkin and test automation techniques in other books (Formulation, Automation). So that readers can focus more on the collaboration aspect.

BDD/ATDD/SBE, what’s difference

The following link is introduced in this book.

[embed]ATDD vs. BDD, and a potted history of some related stuff Another question that people often ask around or to me is, "What's the difference between Acceptance Test Driven…lizkeogh.com

First, Dan North started doing BDD at a unit or class level, as a replacement for TDD (late 2004).

[embed]Introducing BDD I had a problem. While using and teaching agile practices like test-driven development (TDD) on projects in different…dannorth.net

At the end of 2003, I decided it was time to put my money — or at least my time — where my mouth was. I started writing a replacement for JUnit called JBehave, … (omit) It would contain methods that started with the word “should.”

Then, Chris Matts introduced Given-When-Then template and most people who do ATDD use it.

The author of the article “ATDD vs. BDD, and a potted history of some related stuff” said that all of them are the same concept nowadays, but called by different names.

The difference is that one is called Behaviour Driven Development — and some people find that wording useful — and one (or two) is called (Acceptance) Test Driven Development — and some people find that wording useful in a different way.

One of example-driven development

Although it is not mentioned in the book, example-driven development came to my mind in relation to the above topic.

Lisa Crispin and Janet Gregory insist on the power of guiding development with examples in their book More Agile Testing. They learned example-driven development from Brian Marick who is one of the signers of the Manifest for Agile Software Development.

[embed]Example-Guided, A Brief History Over the last few decades, a family of practices emerged that share an example-guided heritage. This articles examines…medium.com

In the early 2000s, he named his blog Exploration Through Example, spoke about Example-Driven Development (EDD), organized an “Examples” stage at the large Agile200x conference and produced a wonderful sticker:

In More Agile Testing, they introduce BDD, ATDD (Acceptance test-driven development), and SBE (Specification by Example) are variants of Example-driven Development.

From this, we can understand that the fundamental concept is to gain a common understanding using concrete examples.

BDD rhythm

In this book, BDD rhythm is explained by the following diagram.

Requirement workshop is similar to the following work, three amigos meeting, discovery workshop, specification workshop, story refinement, product backlog refinement. Many explanations of Example-driven development, not just BDD, began with one of these names. The important thing is to take the time to discuss the details of user stories with business people; the name of the workshop is not important.

Example mapping

This book introduces Example mapping as a meeting format for a requirement workshop.

[embed]Introducing Example Mapping Before you pull a user story into development, it's crucial to have a conversation to clarify and confirm the…cucumber.io

The work format for Example mapping consists of Story, Rule, Example, Question.

• Examples illustrate the concrete behaviour of the system.
• Rules are logical groupings of examples usually focusing on a particular condition. It is also called acceptance criteria, business rules, and requirements.
• Questions or assumptions are any topics that would block the discussion.
• User stories are starting points of discussion.

This workshop seems to be very useful for those who have trouble with a blurred understanding of the system they are implementing. It is common to find out that the specification was misunderstood during sprint review stage after implementation, or just before release without noticing it during relevant iteration. Example mapping can be an effective practice to solve actual software development problems.

I think the sticky notes “Question” is useful. Since these are visible to team members, we can avoid re-discussing these topics again and again.

Concrete example

Concrete examples are key factors for successful BDD. I’ve understood it before but I was vague about how specific it should be.

By the way, I understood each example should mention concrete data, but I’m vague about how specific it should be.

This book give us a useful hint.

Each example illustrates a single rule, and should only mention concrete data that is directly related to the behaviour being illustrated.

When we try to make concrete examples, we tend to make everything unnecessarily specific. I used to be one.

Merit for product owner

BDD can help reduce the product owner’s workload. In BDD, product owners activities would be:

• participate in requirement workshops
• review the scenario
• give feedback about the implemented application

Classic product owner activities are writing specifications, presenting the stories to the team and etc. It is difficult for product owners to continue to have to be the drafter of specifications because they tends to be busy. However, with example mapping, the product owner can get out of the situation of being the “single point of failure”.

Reference books

This book mentions the richness of the examples presented by Specification by Example. Specification by Example is linked as a great reference book by various books, so I also recommend reading it as well.

Here are some books that I’ve read when I was practicing BDD myself.

• Specification by Example
• BDD In Action, Second Edition
• Growing Object-Oriented Software, Guided by Tests
• Test-Driven Development: By Example
• Agile Testing Condensed: A Brief Introduction
• Agile Testing: A Practical Guide for Testers and Agile Teams
• More Agile Testing
• Test-Driven Practical TDD and Acceptance TDD for Java Developers
• ATDD by Example: A Practical Guide to Acceptance Test-Driven Development
• Bridging the communication gap

All of them are good, but The BDD Books is the best in learning the aspect of collaboration, which many books consider to be a fundamental element but fades away as readers read the book latter half of the book.