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.