Behavior-Driven Development vs. Testing

The difference between Behavior-Driven Development and testing:

This is a BDD scenario (from Dan North, a man I respect and admire):

+Scenario 1: Account is in credit+
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned

This is that BDD scenario turned into testing:

+Scenario 1: Account is in credit+
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then check that the account is debited
And check that cash is dispensed
And check that the card is returned
And check that nothing happens that shouldn’t happen and everything else happens that should happen for all variations of this scenario and all possible states of the ATM and all possible states of the customer’s account and all possible states of the rest of the database and all possible states of the system as a whole, and anything happening in the cloud that should not matter but might matter.

Do I need to spell it out for you more explicitly? This check is impossible to perform. To get close to it, though, we need human testers. Their sapience turns this impossible check into plausible testing. Testing is a quest within a vast, complex, changing space. We seek bugs. It is not the process of  demonstrating that the product CAN work, but exploring if it WILL.

I think Dan understands this. I sometimes worry about other people who promote tools like Cucumber or jBehave.

I’m not opposed to such tools (although I continue to suspect that Cucumber is an elaborate ploy to spend a lot of time on things that don’t matter at all) but in the face of them we must keep a clear head about what testing is.

56 thoughts on “Behavior-Driven Development vs. Testing

  1. The other day my college share this blog to me, I went through and said to myself, wow 5 years old blog about BDD, with comments still alive, and decided to add few words on the theme.
    Various gherkin tools were coming in my tester’s life, and I had to use them from time to time.
    Tools were usually used for automation on quite high level using either services or even GUI interface for automation in all those cases. And I was always wandering: how could one write test description in advance, before the tested system is developed, and then provide automation that is linked to the description on a level of test steps? Because this is the main trick with gherkin tools (which management people are usually not aware of) – automation code is linked to the scenario on very detail level!
    Of course (in my experience) it never did work this way. Gherkin statements were always changed after first lines of automation code being written, and then after a while adjusted to the actual automation code. While fairy tale about business people writing gherkin, and then engineers writing automation is still popular it I think there is no such thing at all. BDD stands for Behavior Driven Development I think such thing does not exist in testing, even if we focus just on writing automated regression tests (and forget about other testing for a moment).
    In real life to provide gherkin scenarios that are readable on one hand and related automation comprise in nice reusable library of methods, team that is working on it must be very well aware of how this automation is implemented, and must spend a lot of effort to make it this way. What is most interesting is that gherkin tools are not providing anything to get to this point. It is possible, but
    more often the result is neither understandable gherkin scenarios, nor good library of reusable methods.
    But ‘BDD’ tools are surprisingly still alive after all those years, and they are popular and people are using them, so probably there is something in it! I think answer is simple: they are giving shiny PR for automated regression tests, and that is not negligible. In some cases this is very important. Let us be honest – sometimes it is the most important thing. Not for the testing of course! 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *