Working with BDD (Gherkin Stories)

Overview

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.

Context Questioning

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.


Outcome Questioning

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?”


For instance:

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.


Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select atleast one of the reasons

Feedback sent

We appreciate your effort and will try to fix the article