Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
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
add comment

1 Answer 1

up vote 4 down vote accepted

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.

share|improve this answer
    
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
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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