CODEWITHSUNDEEP
bddui-automationgherkin
Manoj Patel
Manoj Patel

Reputation: 23

How should BDD statements be properly constructed? Is there a convention used in teams?

Is there a preferred way of creating BDD scenarios in small agile teams and amongst the community? I'm using courgette and it gives an example on https://courgette-testing.com/bdd

Scenario: Refunded items should be returned to stock
  Given a customer previously bought a black sweater from me
  And I have three black sweaters in stock.
  When they return the black sweater for a refund
  Then I should have four black sweaters in stock.

Does this sound like a good idea? Would this work well for communication in teams?

I've used their web steps bit, and am now doing the refactor bit to make it clear to the business.

Any links would help. Thanks

Upvotes: 2

Views: 62

Answers (1)

Lunivore
Lunivore

Reputation: 17602

The conversations in BDD are more important than the tools. Rather than starting with the finely-grained specification in Courgette's example, try talking to the business first. Ask them for an example of the kind of behaviour they want.

When you write it down, start by just writing it the way they describe it. It's amazing how few people listen properly! After you've got the example from them, take a look at it. Can you see which bits are the contexts (Givens) and which are the outcomes (Thens)? Which is the step that's associated with triggering the behaviour you're interested in (Whens)?

Once you've worked that out, there are a couple more questions I like to ask:

  • Is there any other context which, for this same event, gives a different outcome?
  • Is there any other outcome that's important?

For instance, if I was implementing this behaviour for a big supermarket, I might come across an example like:

"Oh! No, don't add food back to stock. We don't know how it's been stored. We refund it if there's something wrong with it, but we bin it."

You can probably see how that might change your code!

Testers are really great at asking these questions and spotting missing scenarios! This leads us to the "Three Amigos" pattern. I like to include:

  • A business person, Product Owner, subject matter expert or person with the problem
  • A tester
  • A dev (or a pair of devs).

You can also include UI designers, technical writers, etc. - Matt Wynne says it's "Three Amigos where three is a number between 3 and 7".

I really like it when the developer writes the scenarios down, in any form that allows them to get to the "Given, When, Then". Sometimes I'll do it in the meeting; sometimes I do it later and show it or send it to my business person.

Courgette's example is something that typically happens when people don't have these conversations. If you start with the conversations, you're much more likely to get something that matches the above. Not only are those declarative steps easier for business to read and for the whole team to talk about, but they're also easier to maintain, as the detail of how they're achieved is hidden (usually in Step Definitions, and further in Page Objects).

There's all kinds of useful posts for BDD newcomers on my blog if you want to know more!

Upvotes: 1

Related Questions