I'm wondering how to write BDD test cases for a real system. All examples I can find are trivial and do not answer the question.

Sample use case/story basically goes like that:

  1. User is on the main application page
  2. He clicks retrieve to fetch some order to work on
  3. He fills 4 textboxes and hits submit.
  4. Something happens
  5. The next order is presented to the user

So, point 4 is a little vague, but there is a lot of logic involved, there's a workflow underneath, etc. You could basically define it this way:

Given order of types A+B+C+E+F (20 possible values with arbitraty combination)
  and subtype a1 and the order has attribute X = 1, attribute Y=asdasd, (and much more)
When user enters some specific kind of value in here, and other in here and clicks submit
Then order does this, this, this, this, this, this and that

It does not look good...

So the other way is to write:

Given the order with type A (and the rest is "default")
When user does ...
Then the order does things-depentant-only-on-A

Seems nicer, but - is it really the right approach to define that "default state" of the system? It cannot be arbitrary because "things-dependant-only-on-A" are not really independant - they might not even get a chance to kick in if do-not-take-A-into-account-flag is on, or any other weird special case. (yes, my current project is: some not too complex logic + man-years of special cases)

A note - when we describe requirements we sometimes specify parameters required for the story to make sense, sometimes not - it works for us, because we know other stories. But in BDD it seems that the test case should be specific and unequivocal.

  • can you rephrase the examples in your question with business-language as @AdrianSchneider Suggested? is complex state a mixture of order-payment-mode(i.e. paypal), order-delivery-mode(i.e. via ups), article-properties(i.e. currently not in stock) and other sub-domains?
    – k3b
    Aug 3 '13 at 7:20

You should be describing it using terminology that makes sense to the business, not to a HTTP client. For example,

Scenario: Mark Order as Pending
  Given we have an Order Y        // creates order
   When the user edits Order Y    // click/load edit page
    And marks it for review       // toggles tickbox #3
   Then it should show up in the pending review list

BDD is all about describing the intended behaviour. Focus less on describing implementation. While the latter is easier, and typically what you see in tutorials, you end up with a ton of repetition and confusing tests.

  • This sounds right, but the behavior is mostly driven by "order configuration" (tons of parameters) and business is aware of them. User actions just add few more parameters and trigger the processing. E.g. your example - should it be - given we have an order Y with 2 suborders, coming from a contract, for a one of hazardous products, etc.. - you get the point.
    – mabn
    Aug 3 '13 at 12:04
  • 1
    Actually, @mabn -- I think you are missing the point, and quite possibly so are your business analysts. The point of BDD is not to describe the underlying work the application is doing, but to describe the behaviour of the user. BDD is delving out the stories based on what tasks the user needs to do, as that determines the interface. As you develop the code that implements that story, you then use TDD to create unit and functional tests to determine what to actually implement.
    – tamouse
    Aug 3 '13 at 14:59

So, If I understand you correctly, you're asking how we could formulate our gherkin scenarios in such a way that we are only covering one thing whilst the problem is that the outcome depends in fact on several things.

I think an example of this would be something like - a table booking system with the rules: cannot book on weekends and age of user must be 18+

The When step is the command we give the system - e.g. book table

So you're scenario would have to specify in the Given step with information about both the current time (e.g. not weekend) and the age of the user (18) - even though you're only interested in your scenario covering one rule - what happens when user is under 18

One solution is to move the step about Given the current date is x/y/z to the Background so that it's executed before every scenario, and make this feature file only about the age rule.

Then you would have to create another feature file with the step Given Mark was born on /x/y/z/ put into the background so that each scenario is specifically about weekend and non-weekend dates.

In this way your Then is "dependent" only the Given in the scenario. (even though in reality it's not independent - but the test for the other factors is tested elsewhere and so can be conceptually "ignored")

And just to make something clear - the Then, the outcome is essentially a new state that the system is in. This "something happens" in your step (4) means something changes in the systems state. So it would not be next order presented to user but what has changed in the system as a result of the When command - for example your next order id may have been incremented, a notification may have been sent out, stock might have been updated etc. Those are the things you're interested in asserting.

As far as the presentation to the end user is concerned BDD doesn't have much to say and it often therefore mis-applied. Lets say that your business rule for sys-admins is when they go to www/order/enter - they are always presented with a form using the current/last-incremented order id. You can write a very simple (integration) test to check this.

The fact that the form is correct, at least in the sense that it contains the right input elements, can be ascertained by running the When command via the browser (automate the browser) - if you get the right outcome (db or system-state), then the form works fine as far as user input is concerned.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.