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:
- User is on the main application page
- He clicks retrieve to fetch some order to work on
- He fills 4 textboxes and hits submit.
- Something happens
- 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.
1
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.
2
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.