With my new job, I’ve not been able to take advantage of a lot of Agile/XP practices.  In a company of four, where each is effectively working on a different project, collaboration is minimal.  Also, for the projects that I am working on, the customer is very adamant about getting a detailed proposal up front, including a list of all of the screens and how they will operate.  I’ve managed to get by without too much detail, but it is still more than I am generally comfortable with.

TDD and Continuous Integration are about the only Agile practices that I have kept up.  I have neglected to document user stories and acceptance tests.  I’ve let my unit tests be the extent of my documentation beyond the initial proposal.  As much as I would have liked to use something like Fit/Fitnesse to interact with my users for acceptance, it just wasn’t going to work.

Blah, blah, blah… and more to the point.

After reading extensively about BDD, I’ve discovered that the primary purpose is not to change how tests are arranged, but to bring acceptance criteria from the customer to the code with as little translation as possible.

I’ve written hundreds of tests for my new project in the last year.  I have also extensively refactored my test code and introduced a variety of classes to simplify testing my MVP classes.  I’ve hidden as much of the noise as I can.

My tests typically look something like this:
    1 [Test]
    2 public void MyVeryWellDescriptedTest()
    3 {
    4     Test.WithExpectations( () => ...)
    5         .WithActions( () => ...)
    6         .WithAssertions( () => ...)
    7         .Execute();
    8 }


The combination of this TestBuilder wrapper along with my base test classes has really simplified my tests.  Switching to BDD style would be a lot of work and it didn’t appear that it would add a lot of benefits.  I didn’t like the fact that I would have to add a separate class for each scenario.  I didn’t like that the pieces important to my test would be broken up between multiple methods.  I didn’t like the fact that I would need significantly more lines of code noise to write my tests.

I played around with my naming conventions for my tests to be more BDD like.  I added underscores and have been a lot more verbose.  I still haven’t decided if I really like the new naming convention.

But this all misses the point of BDD.  I look at my tests and think, these are readable.  Well, I’m just fooling myself.  First, a glance at my tests doesn’t immediately give an indication of the behavior that they are testing.  Second, only someone familiar with Rhino Mocks would really understand the tests without some guidance.  Finally, you can’t call your own code readable, just like you can’t give yourself a nickname.

In fact, I have gone back to some tests that I wrote toward the beginning this project.  The tests are about nine months old.  They are not easy to read and I am the author.  They are not horrible, but I think BDD could have improved them dramatically.

I am starting a couple of new projects soon, so I think I will go full bore into BDD.  In fact, I prototyped some ideas with a coworker while he was visiting from out of town.  We both agreed that the BDD tests were easier to read, and they clearly expressed the intended behavior of the system.

What are your experiences with transitioning from TDD to BDD?

Tags: , , ,
posted on Tuesday, March 3, 2009 9:03 AM
Filed Under [ Agile Quality TDD BDD ]

Comments

No comments posted yet.

Post A Comment
Title:
Name:
Email:
Comment:
Verification: