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.

58 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! 🙂

  2. Six years on now and the relentless march of Cucumber continues unabated. When are businesses going to stop using testers as admin staff and start using testers to test?

    I have never worked with a client who has the BAs writing the Feature files and the developers writing the Step Definition files, it always gets left to the testers. This is complete nonsense!

  3. From Aslak’s web site – https://cucumber.io/blog/2014/03/03/the-worlds-most-misunderstood-collaboration-tool:

    “What many didn’t realise was that Cucumber was now taken out of its intended context: Collaboration.

    When Cucumber is adopted solely as a tool to write automated tests without any input from business analysts they tend to become imperative and lose their documentation value.

    This also makes them slow and brittle.”

    Why is nobody listening to the guy who came up with Cucumber?

    Too many test managers are box ticking and not standing up for their test teams.

    [James’ Reply: I don’t get it as a collaboration tool. We already have talking. We already have writing. I don’t get why I should adopt a stilted style of writing and try to fit all my communication into that style. I don’t think that improves communication– it discourages communication that doesn’t fit into that simple model. Certain technocrats like it, but I’m a technocrat who wants to encourage everyone to talk or otherwise get their ideas across, in ANY way that is comfortable to THEM.]

Leave a Reply

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