Behavior-Driven Development (BDD) is an agile software development practice that
enhances the paradigm of Test Driven Development (TDD) and acceptance tests. It
encourages the collaboration among developers, quality assurance, domain experts, and
stakeholders. Test Driven Development (TDD) mainly relies on the repetition of a very
short development cycle, where the developer writes an (initially failing) automated test case
that defines a desired improvement or new function, then produces the minimum amount of
code to pass that test, and finally refactors the new code to acceptable standards however,
Behavior-Driven Development, primarily focuses on obtaining a clear understanding of
desired application behavior through discussion with stakeholders using a Ubiquitous
language, which is lucid and easy to comprehend.
Behavior-Driven Development was introduced by Dan North in the year 2003.
BDD, principally being an idea about how software development should be managed by both
Business Analysts and QA teams, it also assumes the requirement of specialized software tools
to support the development process and for intended use in BDD projects.
Conversational patterns in BDD
BDD is all about the conversations you have, exploring examples (or scenarios) of an
application’s behavior, to see if everyone has the right understanding. We’ve got a good chance
of discovering what someone else knows, and has perhaps forgotten to tell us, if we start
questioning the ways in which our understanding might be wrong. These are two patterns which
are commonly used.
We can ask, “Is there any other context which, when this event happens, will produce a different outcome?”
It might be an additional context, or a context which occurs instead of the one(s) we’re
considering. We can ask this question, or we can think of contexts ourselves and ask about
those. For instance:
Given a salesperson, Tom, wants to sell three cars, Volkswagen, Fiat and Honda
When Tom uses the application
Then Tom should only be able to see the price of Volkswagen, Fiat and Honda
As a Test Engineer, one will have obvious question “Given I have no cars, what happens then?”
The Head of showroom says, “Who cares? Why are you even using the application? Go & get
some clients already!” (He’s thinking of his failing business.)
Even though the behavior of the application is not going to change immediately, still a lot can be
learnt about business domain this way.
This is similar to Context Questioning, but instead, we ask.
“Given this context, when this event happens, is there another outcome that’s important?
Something we missed, perhaps?”
Given the serverX of shopping site has a problem
When a user bought a gift
Then the user should be told about the problem
You’ll wonder, “Is that all that should happen? I’d be upset if I was a user and this happened a lot.”
My business analyst says, “Well, we’ll still have the details in the system, so you’ll be able to
do it again later. Oh, yes! We need to store the details of the gift in our system still, too, but
make sure it doesn’t have a ServerX ID so that we can tell it didn’t go through.”
There are lots of other ways to have conversations around behavior. They’ll usually be trying
to find missing contexts and outcomes – places where a new piece of behavior happens.
These also tend to be the things which business users, familiar with their domains to the point
where they don’t think about it, forget to talk about. Developers are pretty good at spotting
this, because they’re usually thinking through how they’re going to implement the problem,
and wondering what goes on the other side of the “if… else…” statement (even if we’re not
meant to be implementing yet, we already are in our heads). Testers are also very good,
because they’re used to the kind of things people get wrong when they produce software.
This is why getting all three people – a tester, a developer and a business analyst – is so useful
when we’re discussing scenarios. It’s also why it’s so important to have the conversations –
because if you’re not having conversations, you’re not doing BDD.