How specific do I get in BDD scenarios?

Question

Take two different ways of stating the same behavior.

Option A:

Given a customer has 50 items in their shopping cart
When they check out
Then they will receive a 10% discount on their order

Option B:

Given a customer has a high volume of items in their shopping cart
When they check out
Then they will receive a high volume discount on their order

The former is far more specific. If someone has some question about exactly when a customer gets a high volume discount or how much to give them, reading this scenario makes it very clear. Serving the purposes of documenting the behavior, it's about as specific as it can be, although any change in those values will require changing the scenario.

The second is more generalized and doesn't have the clarity of the first. Automating it would require incorporating the values "50" and "10" in the step implementations. On the other hand, the scenario captures the core business need: a high volume customer gets a discount. If we later decide to use "40" and "15", the scenario doesn't have to change because the core business need hasn't really changed (though the step implementation would). Also, the term "high volume customer" communicates something about why we're giving them the discount.

So, which is better? Rather, under what circumstances should I favor the former or the latter?

Answer 1

I think I'll go for option A.

The thing is that BDD scenarios must serve as documentation of the system.

So if a non technical wants to know how your discount system is working (A business guy, a tester or someone from the customer support team), they surely would like to know what it means to have a high volume of item and what it is the applied discount. And they would not want to have to go in the plumbing code to get this information back.

I think this information is important and can not be hidden from the reader.

Another benefit is that it will allow for a non developer (a tester for example) to write new scenarios and check what will happen if there are 1 item in the cart or 100 items.

When you get too much abstract about thing, it gets harder to apply deliberate discovery. So with a scenario as in Option B, you loose the opportunity to ask your self these questions:

• What happen if we have more than 50 items like 100 items is there any other discount available
• What happen if we have 1 item, surrely we need to not apply a discount or should we apply a discount based on the total price of the cart instead of the number of items in it, someone buying only one really expensive item should benefit a discount too ?
• is 10% the only available type of discount, do we have for example fixed amount discounts ? Do we have more complex discount strategies ?

When the business variable are visible, you can play around with them and figure out stuff that you may have forgotten or think about new interesting (or not) features.

As a general rule, I'd hide what it does not matter to know in a scenario and in that case the number of items and the applied discount value do really matter to the reader.