IronRuby, BDD, and Me

If you haven’t read the definitive paper on Behavior Drive Development (BDD), I would encourage you to stop reading now and do so.  http://dannorth.net/introducing-bdd

Now, before we dive into using IronRuby and Rspec any further, I wanted to look at BDD beyond just the technical definition.  Sure, things like “tests should be sentences” and “conditions of acceptance should be executable” are important… but in reality, you can do ALL of those things with other testing approaches.  So, why BDD… what does it add?

The answer for me is that before you write software you should be thinking in terms of it’s actual value.  In short, what SHOULD the application do.  And what, explicitly, should it NOT do.  The rest should work itself out through emergent design.

Some people say that BDD is TDD done right.  I cannot honestly comment on that statement, because I have never seen TDD done right.  What I’ve seen instead with TDD has been a focus on the technical correctness of code, not the functional correctness of it.  Thing is I don’t really care much about technical correctness… not first, at any rate.

Don’t get me wrong, unit tests, functional tests, integration tests are important, they just often confuse the issue.  At the end of the day, tests have only one purpose… to prove your application works.  Instead the approach I’ve seen is akin to trying to prove an actress has memorized her lines, before worrying about finding the right actress who represents the character.

Worry about the first most important problem first.  Then worry about the next first most important problem.

So where does that leave you?  I still want to prove correctness, but not be married to implementation too soon.  If you start testing code’s technical correctness BEFORE it has proven it’s functional correctness, you’ve already written vows.

What this translates to pragmatically is an approach like this:

    1. Use conditions of acceptance to build tests that prove your code’s ability to meet them.
    2. Write the code! 🙂
    3. Write more tests when:
      1. New requirements demand new functionality.
      2. Defects are entered into the system.
    4. Refactor your design of code to solve them.

In closing, BDD resonates strongly with me because I believe you don’t know what you don’t know.  Instead of focusing on technical correctness of code you haven’t written, you do know what your software should do (based on requirements & specs) and you should be able to prove you have done them.

-A

Advertisements
Post a comment or leave a trackback: Trackback URL.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: