Get ebook downloads in full at ebookmeta.

com

The BDD Books Discovery Explore Behavior Using

Examples Gaspar Nagy

https://ebookmeta.com/product/the-bdd-books-discovery-
explore-behavior-using-examples-gaspar-nagy/

OR CLICK BUTTON

DOWNLOAD NOW

Explore and download more ebook at https://ebookmeta.com

 Recommended digital products (PDF, EPUB, MOBI) that
you can download immediately if you are interested.

BDD in Action: Behavior-Driven Development for the whole

software lifecycle, 2nd Edition John Ferguson Smart

https://ebookmeta.com/product/bdd-in-action-behavior-driven-
development-for-the-whole-software-lifecycle-2nd-edition-john-
ferguson-smart/
ebookmeta.com

Learning Behavior driven Development with JavaScript

Create powerful yet simple to code BDD test suites in
JavaScript using the most popular tools in the community
1st Edition Enrique Amodeo
https://ebookmeta.com/product/learning-behavior-driven-development-
with-javascript-create-powerful-yet-simple-to-code-bdd-test-suites-in-
javascript-using-the-most-popular-tools-in-the-community-1st-edition-
enrique-amodeo/
ebookmeta.com

Regex Quick Syntax Reference: Understanding and Using

Regular Expressions Zsolt Nagy

https://ebookmeta.com/product/regex-quick-syntax-reference-
understanding-and-using-regular-expressions-zsolt-nagy/

ebookmeta.com

Soundtracks The Surprising Solution to Overthinking 1st

Edition Jon Acuff

https://ebookmeta.com/product/soundtracks-the-surprising-solution-to-
overthinking-1st-edition-jon-acuff/

ebookmeta.com
New Nebraska Lessons 1st Edition Cara B King

https://ebookmeta.com/product/new-nebraska-lessons-1st-edition-cara-b-
king/

ebookmeta.com

Death by Society 1st Edition Sierra Elmore

https://ebookmeta.com/product/death-by-society-1st-edition-sierra-
elmore/

ebookmeta.com

Entrepreneurship Business Debates: Multidimensional

Perspectives across Geo-political Frontiers Vanessa Ratten

https://ebookmeta.com/product/entrepreneurship-business-debates-
multidimensional-perspectives-across-geo-political-frontiers-vanessa-
ratten/
ebookmeta.com

Home, Memory and Belonging in Italian Postcolonial

Literature 1st Edition Chiara Giuliani

https://ebookmeta.com/product/home-memory-and-belonging-in-italian-
postcolonial-literature-1st-edition-chiara-giuliani/

ebookmeta.com

The Distributional Impact of Taxes and Transfers Evidence

from Eight Developing Countries 1st Edition Gabriela
Inchauste
https://ebookmeta.com/product/the-distributional-impact-of-taxes-and-
transfers-evidence-from-eight-developing-countries-1st-edition-
gabriela-inchauste/
ebookmeta.com
Curse of the Forgotten City 1st Edition Alex Aster

https://ebookmeta.com/product/curse-of-the-forgotten-city-1st-edition-
alex-aster/

ebookmeta.com
The BDD Books - Discovery
Copyright © 2019 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any
form or by any means, without the prior written permission of the publisher, except in the case of brief
quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information
presented. However, the information contained in this book is sold without warranty, either express or implied.
Neither the authors, nor Packt Publishing, and its dealers and distributors will be held liable for any damages
caused or alleged to be caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products
mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the
accuracy of this information.

Authors: Gáspár Nagy and Seb Rose

Managing Editor: Aditya Datar

Acquisitions Editor: Bridget Neale

Production Editor: Samita Warang

Editorial Board: David Barnes, Mayank Bhardwaj, Ewan Buckingham, Simon Cox, Mahesh Dhyani, Taabish
Khan, Manasa Kumar, Alex Mazonowicz, Douglas Paterson, Dominic Pereira, Shiny Poojary, Erol Staveley,
Ankita Thakur, and Jonathan Wray

First Published: July 2019

Production Reference: 1260719

ISBN: 978-1-83921-182-9

Published by Packt Publishing Ltd.

Livery Place, 35 Livery Street

Birmingham B3 2PB, UK

Table of Contents
Preface
Chapter 1: What Is BDD?
Introduction
The Missing Link
How Does BDD Work?
What About Testing?
A Language That Is Understood By Everyone
Living Documentation
What Is BDD, Then?
What We Just Learned
Chapter 2: Structured Conversation
Introduction
Where Is My Pizza?
A Useful Meeting
Collecting Examples
Deliberate Discovery
Example Mapping In A Nutshell
How To Establish Structured Conversations
What We Just Learned
Chapter 3: What Is an Example?
Introduction
How Hard Is Concrete?
Is All That Concrete Essential?
How Many Examples Do We Need?
Why Stop Now?
Rules Versus Examples
My Example Illustrates Multiple Rules!
The Bigger Picture
What We Just Learned
Chapter 4: Who Does What and When?
Introduction
The BDD Approach
BDD in Scrum
Requirement Workshops
Formulate
How Scenarios Help With The Decomposition Of
Stories Into Tasks
BDD in Lean/Kanban
BDD in Distributed Teams
Requirement Workshops With Distributed Teams
BDD In Fixed-Scope Projects
BDD In Regulated Environments
What We Just Learned
Chapter 5: How to Get Business Involved
Introduction
Learn From Your Peers
The One Where The Business Is Not Involved
BDD Is For Solving Problems
The Product Owner Is Overloaded
Production Issues Are Common
It Is Hard To Get The Product To A Deliverable State
It Is Hard To Get Customers Engaged With The
Product
Deadlines Are Often Missed
Hard To Get A Good Overview Of Progress
Introduction Of New Features Causing Unwanted
Side Effects
Not Being Able To React Fast Enough To Market
Changes
Bug-Versus-Feature Debates Within The Team
Changes Regularly Requested At Sprint/Feature
Reviews
But My Product Owner Never Reads The Scenarios
What We Just Learned
Appendix
What's next
Where are we now?
Preface
About
This section briefly introduces the authors and what the book covers.

About the Book

BDD is an Agile approach to software development that insists that detailed requirements for a feature should
be defined collaboratively by the business and delivery teams. The output of this collaboration is documented
using business terminology that can be understood unambiguously. Finally, the documentation is structured in
a way that enables it to act as automated tests that verify that the system behaves as intended. This book
explores, in detail, the collaborative aspect of BDD.

BDD has been proven to be successful in thousands of projects around the world, on different platforms, in
diverse industries and various project sizes. BDD is based on a set of practices that originate from the
experience of many people over many years, working to uncover better ways of delivering software. However,
there is a learning period (or, more accurately, a practicing period) for BDD, so it will take some time before
you start seeing a return on your investment.

We belong to the second generation of the software industry (we could call ourselves Generation Y – there
are a lot of similarities). We don't believe in buzzwords or well-named methodologies, but we like to try them
out to see whether they work. So, if you try out BDD, how can you decide whether it has worked or not?

The first indicator you are likely to notice is a reduction in cycle time. The shared understanding that is gained
during collaborative requirement definition sessions ensures a smooth flow from definition to delivery. If a
developer or a tester discovers an ambiguity in a requirement once they have started working on it, they'll
need to resolve it. This interrupts their work, as well as the work of any colleague that they have asked to
help. The elimination of interruptions and context switches leads to a more efficient, more predictable delivery
process.

Another visible indicator is a reduction in the number of production issues. Although it is very hard to gather
scientific evidence of this (because it is hard to find a control project), we have seen significantly fewer
production issues in projects that have successfully adopted a BDD approach.

BDD helps preserve the quality and maintainability of the software, so a further indicator is that the
implementation costs of new features are kept low. This is in contrast to many other projects where, as the
code base grows, the cost of adding (or modifying) a feature increases exponentially. If allowed to deteriorate
in this way, your project will finally reach the point where it is not possible to add new features anymore in a
cost-efficient way and people will start talking about a rewrite.

Our goal with this book is to ease your way through the learning period, avoiding the mistakes that we made
while we were learning.
One typical mistake is to see BDD as a tool box. BDD is primarily about collaboration and domain discovery;
any BDD tool can only be useful in supporting this process. You have to start by investing in collaborative
discussions and the creation of a shared vocabulary. Just going after automation (using Cucumber or
SpecFlow) does not work.

It doesn't. Honest.

As we said, we don't believe in buzzwords, but if you intend to evaluate the BDD approach objectively, it is
important to do it at full throttle during the evaluation period. You might feel uncomfortable or skeptical when
you start doing BDD (as with any other new approach). That is absolutely fine, but don't let the evaluation be
hampered by your fears. Once you have decided to evaluate how BDD could work for your team, give yourself
enough time to get comfortable with the approach. Try, as far as possible, to follow our recommendations.
You're at the beginning of a brave new world. Let's help you to explore that world and discover the benefits
that are waiting.

Learning Objectives
Explore why BDD exists, what challenges it addresses, and how it works.

Establish structured conversations to finalize requirements.

Discover techniques to form concrete examples that clearly list requirements.

Gain insight into the tasks involved while following the BDD approach.

Get good automated test coverage by tightly connecting tests and scenarios.

Develop scenarios to get a functional breakdown of a story audience.

Audience
This book is written for everyone involved in the specification and delivery of software (including product
owners, business analysts, developers, and testers). This book is aimed at everyone involved in the project,
irrespective of your role, whether you come from a software background or not.

Approach
This book explains the specific technical practices that are needed to successfully drive development using
collaboratively-authored specifications and living documentation. It uses easy-to-understand language and
real-life examples that you will relate to.

About the Authors

Gáspár Nagy is the creator and main contributor of SpecFlow, which is the most widely used Acceptance
Test Driven Development (ATDD)/ Behavior-driven BDD framework for .NET. He is an independent coach,
trainer, and test automation expert, focusing on helping teams implement BDD and SpecFlow through his
company, called Spec Solutions. He has more than 15 years of experience in enterprise software development
as he has worked as an architect and Agile developer coach. He shares useful BDD tips related to testing
automation on his blog (http://gasparnagy.com) and on Twitter (@gasparnagy). He edits a monthly
newsletter (http://bddaddict.com) about interesting articles, videos, and news related to BDD, SpecFlow, and
Cucumber.

Seb Rose has been a consultant, coach, trainer, analyst, and developer for over 30 years. He has been
involved in the full development life cycle with experience that ranges from Architecture to Support, from
BASIC to Ruby. He is a BDD advocate with SmartBear, helping people integrate all three practices of BDD into
their development processes and ensuring that appropriate tool support is available. He is a regular speaker at
conferences and occasional contributor to software journals. He is the co-author of the BDD Books series'
"Discovery" and "Formulation" (leanpub), lead author of "The Cucumber for Java Book" (Pragmatic
Programmers), and contributing author to "97 Things Every Programmer Should Know" (O'Reilly). He blogs at
smartbear.com and tweets as @sebrose.

Together, Seb and Gáspár have over 50 years of software experience.

Acknowledgements
This book would not have been possible without the help of our reviewers Gojko Adzic, Garret Burns, Darren
Cauthon, Lisa Crispin, Claude Hanhart, Dave Hanlon, Sam Holder, Alexandra Fung, Adrienn Kolláth, Gilbert
Liddell, Viktor Nemes, Paul Rayner, Chuck Suscheck, Steve Tooke and Andreas Willich.

Foreword
By Johanna Rothman

As a consultant, I see Agile projects in trouble. Why? Because the requirements mean one thing to one person
and another thing to another person. The team, the product owner, the business people – all of them have a
different perspective on what the requirements are and what they mean.

Those people need this book.

In my 40+ years of experience, I've heard, "We'll know what's in here once we ship.” Or, "It's not done if the
whole thing isn't done.” Or, "Let's get the bones of this requirement in and refine it later.”

Those sayings weren't horrible. However, I've seen teams veer off in various directions that the customers
didn't want or need, or that the product manager/owners didn't want. These teams (and others) suffered from
the same problem: we didn't have examples to understand the requirements.

When we have examples, we – all of us, including team members, product owners, business people,
managers of all stripes – can discuss the reality of the work. Without examples, we flounder. Worse, we don't
just delay the delivery of valuable features, we even implement the wrong work. We don't receive feedback
early enough.
This book can change that for you. By defining the behaviors of your product, and by creating, refining, and
using examples, your team can get faster feedback and deliver the product your customers need.

Gáspár and Seb guide you through thinking and practicing the discovery part of BDD in this book: How to
discover the requirements. They explain how discovery is followed by formulation (turning the examples into
scenarios) and automation (using the scenarios to test the behavior).

It sounds easy. It's challenging to do, only because we often don't think of doing these three steps in this
order.

One of the problems I see in teams is that, too often, the product owner (or some responsible person) takes
orders from other people. The product owner doesn't always understand the requirement itself. BDD can help
expose that problem through collaborative conversations.

Or, sometimes, the team is supposed to be like a short-order cook, taking the requirements from the product
owner without conversations. That rarely works, and this book has an entire chapter on how to build the
requirements through conversations.

Some of my clients are a little stuck on rules, examples, acceptance criteria, and how to use them properly.
Gáspár and Seb devote one chapter to explaining what the examples are and how to frame them. I appreciate
the positive way of structuring examples, even on the paths you want to prevent people from exploring in
your product.

There's a chapter that addresses who does what and when. Because Agile approaches are a system, it's not a
flow chart – Gáspár and Seb created a diagram that shows how the various practices that make up the BDD
approach interact. They emphasize that a business review of the team's work is needed and clarify how BDD
practices tie into implementation and refactoring. They also explain how you might have additional tests and
when you might release the product.

The last few chapters discuss how to use BDD in almost any project – not just Agile approaches – and how to
involve your business partners.

Read this book to start using BDD effectively. You, your team, your customers, and your managers will all be
glad you did. I can't wait for the next book!

Johanna Rothman

Consultant, author, and speaker

Arlington, Massachusetts

What is not in this book:

Formulation

Structuring documentation

Gherkin
Tools

Automation

Code
Chapter 1
What Is BDD?
Introduction
Behavior Driven Development (BDD) is an agile approach to delivering software that has been gaining
momentum over the past ten years or so. In this chapter, we take a look at why BDD came into existence, what
challenges it addresses, and take a high-level look at how it works.

Seb's story: BDD, ATDD, or Specification By Example?

I used to get confused by all the different names that I read in blog posts. There was Behavior Driven
Development (BDD), Acceptance Test-Driven Development (ATDD), and Specification By Example. I tried
to work out how they differed, but eventually, I realized (aided by Liz Keogh,
http://lizkeogh.com/2011/06/27/atdd-vs-bdd-and-a-potted-history-of-some-related-stuff/) that they were just
different names for the same thing.

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 requirements. Waterfall methods had slow feedback cycles built into
them, allowing projects to go seriously off track. In response, the industry began to experiment with
lightweight methodologies, such as XP and Scrum.

Agile iterations are often wrongly implemented as mini-waterfalls. Teams spend weeks implementing a user
story. After that comes testing, to make sure they got it right. When they discover a mistake, they have to fix
the problem and retest the story — a tedious and time-consuming process. The resulting delay in feedback
continues to limit the benefits that agile development methods can deliver:

Figure 1.1: Agile mini-waterfall

Test-Driven Development (TDD) helps speed up the feedback loop by demanding that teams write
automated tests before they write the code. That in itself is not enough.
Gaspar's Story: Automation Is Not Enough
In a company I was working for, testing new features was always chaotic. We never did any testing until after
the feature was done, and it was only then that we discovered we had misunderstood things that had
previously seemed obvious. Unfortunately, since this testing was all manual, things did not get any better after
this. We continued to need real people running through test scripts to make sure that the application still
behaved as expected. Tedious, manual regression testing.

We needed automation – this is how we wanted to improve the regression testing problem. In addition,
automating our scripts required us to write code, and the code became hard to follow, even for other
developers. This prevented discussions about misunderstandings and different interpretations of the obvious.
We needed a solution that made tests automatable but preserved their connection to requirements.

In the early days, JUnit required developers to use the word test in their method names, and this
overemphasized one goal of unit tests (testing) at the expense of other goals, such as design, documentation,
and definition of the expected behavior. By giving them a name such as OrderTest, they become detached
from the business requirement as soon as the test has been completed. And, as time goes by, this gap gets
bigger and bigger.

Dan North noticed this problem and suggested some practical rules for naming and structuring the test
methods to preserve their connection with the requirements (similar problems had been observed by other
people, such as Kent Beck with Customer Tests (Extreme Programming Explained: Embrace Change), Joshua
Kerievsky (https://www.industriallogic.com/blog/storytest-driven-development-article/), Ward Cunningham
(http://fit.c2.com/), and Eric Evans (Domain-driven Design: Tackling Complexity in the Heart of Software). He
also explained that the easiest way to verify whether our tests expressed the expected behavior was to show
them to business representatives. However, business people rarely read source code, so he developed a small
tool that performed a few simple transformations to make the test results business-readable.

He called this concept Behavior Driven Development (BDD) (https://dannorth.net/introducing-bdd/),

intentionally removing the word test to encourage business people to remain engaged throughout the
process. BDD helps maintain a connection between the requirements and the software, and, as such, acts as a
bridge. Gojko Adzic even called his first book Bridging the communication gap (Adzic, Gojko. Bridging the
Communication Gap: Specification by Example and Agile Acceptance Testing. London: Neuri, 2009. Print.).

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, and you document the
requirements. Business people remain engaged because the examples are expressed in business language. Fast
feedback is preserved because the examples are automated.

These examples are often written using the Given, When, and Then keywords introduced by Chris Matts
(https://theitriskmanager.wordpress.com/about/) and called scenarios:

Scenario: Allow address change while the order is in preparation

Given the client's order is currently in preparation

Other documents randomly have
different content