B.D.D. Thoughts Reloaded

Scott StultsMay 3, 2010

Its not exactly easy to get people to read requirement or technical specifications, much less write them. It’s also hard to get  developers to write tests. Its even harder to get them to write solid usable tests. B.D.D (Behavior Driven Development) which is a spin off of T.D.D (Test Driven Development) focuses on the language of testing and and quality assurance of software, in hopes to make creating tests easier as well and specifications. The concept was coined by Dan North. Since then new libraries like rspec, cumcumber, specflow, nbehave, machine spec have come about. I can agree that sometimes changing the business language can help people with making associations and understanding of processes easier. And using “Behavior” instead of “test” does help in understanding that you need to validate how the software or code is supposed to behave.

Questioning The Boilerplate –  Human Readable Specifications

Where people need to be more skeptical is the question of is there real business value in getting code to generate boilerplate systematic specifications? For an example, I’m pulling this from a

cucumber example from github.

# language: en
Feature: Addition
  In order to avoid silly mistakes
  As a math idiot
  I want to be told the sum of two numbers

  Scenario Outline: Add two numbers
    Given I have entered <input_1> into the calculator
    And I have entered <input_2> into the calculator
    When I press <button>
    Then the result should be <output> on the screen

  Examples:
    | input_1 | input_2 | button | output |
    | 20      | 30      | add    | 50     |
    | 2       | 5       | add    | 7      |
    | 0       | 40      | add    | 40     |

We live in a time surrounded by constant news, media, following four subplots instead of one. Its hard to get people concentrate for long periods of time or sit still, much less to get them to read technical or requirement specifications. Now I was to write this scenario for a requirement out as a spec, it would read like the following.

The mad scientist2 with his destructo calculator enters input 1 and input2. He manically presses said red button . The output must be the sum of input 1 and input 2.

(i1 + i2 = output)

So why are we creating specifications that repeat words like I,As,When,Given,Then like bad boilerplate code? They might be human readable, but the questions of being understandable, easy to read, enticing to read, is a whole different story. I have to honestly question that even if a developer takes their time and makes sure the code is up to spec. The question is are the specs kept up to day (requirements change). And are lay people going to want to sit through and actually read these things? Is this a real business value? I don’t see any at this point. I see no real return on time invested to write boring systematic specs and just to have them match up in some way with code. Specifications, like any documentation worth it’s salt, needs to be able to:

  • be engaging and appeal to more than the logical side.
  • provide the meat of information that is digestible.
  • avoid templating that read like government contracts.
  • be terse and yet expressive.

We have been here before

Their have been tools like this — (Fit,Finesse) — before Dan North was really doing this thing. Yet you don’t see much usage from them across projects. I think the reason why cucumber has caught on, is because the rails community has been keeping momentum from going from one “next big thing” onto the next one. Cucumber is the new pink. But the end result is the same. Less than specular on par with boring. Hard to digest boiler plate specifications. Don’t get me wrong, having specifications to work from is important. It helps to drive development and allows others to collaborate and work together. But this doesn’t mean B.D.D is on the right track with its story/QA methodology. I think there is value of translating specs into code to some degree and testing against requirements. I think the value is lost when:

  • coders who might not fully understand the business are writing specs.
  • business analysts who have no clue to code write specifications that affect how code is written.
  • specs written  in a templated manner that is the antithesis of being terse.

Should vs Must

Also the domain language is for B.D.D. a bit off. If you’ve read technical specs, you know there is a vital difference between “Should” and “Must”. Should is something software could do, but doesn’t have to. Must is an absolute requirement. If you don’t believe me, check out the W3 specs sometime. Yet, we’ve chosen “should” for some reason to put everywhere inside of our “specification” code. If we’re going to write specifications, we must chose words that fit.

Conclusion

B.D.D. isn’t evil or bad, but still needs to evolve, be debated, thought on, expounded. I think the software community as a whole needs to watch out from getting caught up too much in trends for the sake of being first to do something and buying the t-shirt to say he/she was there.




More blog articles:


Let's do a project together!

We provide tailored search, discovery and personalization solutions using Solr and Elasticsearch. Learn more about our service offerings