Agile Austin Open Space

The Agile Austin Open Space kicks off this evening with agenda and topic setting. You can find the proceedings documented on the wiki at: openspace.agileaustin.org

I will be blogging about proceedings as I see things interesting. Be sure to watch the wiki.

Why Behavior Driven Development?

Two years ago, I became completely test-infected. I hate writing implementation code without writing the test first. Then, about six months ago, I was introduced to Behavior Driven Development (BDD). I liked what I saw, but I really didn't see any tools that I wanted to bring into our build system. The last thing that I wanted to introduce to the company was another test framework. JUnit was meeting our needs fairly well, and we were already using FitNesse on our team whereas the rest of the company was not. We didn't want to add another tool on top of that.

Then, a few months ago, I saw Scott Bellware give a talk on BDD and saw how he simply did BDD within a normal unit-testing framework and used .Net attributes to markup the tests with the BDD language. I liked what I saw. That night, I started a similar tool for JUnit called EasySpec. The tool still has some kinks to work out, but BDD has definitely brought some interesting insights into how we design our tests.

So, why BDD? At first, it was simply a trial of a style that seemed to do a good job of pulling out the Ubiquitous Language. Now that we have been using the techniques for about three months, I must say that I really like using BDD for creating software -- especially around the Domain Model.

BDD cleans up the language and gets the developers talking more about behaviors and less about implementation. Where, in the past, I might have been tempted to write a test with a method name like, "the_service_should_throw_an_exception_if_the_user_is_not_authenticated," I would now write that same test with a name like, "the_service_should_require_authenticated_users." Internally, the test would still be implemented in the same fashion, with probably the same code. However, language is important. It's important for the developers to think in the domain rather than hiding in the implementation layer. If I'm interested in the details of how the service requires authenticated users, then I can look at the details of the test (which should still be cleanly written) and see that in fact, the service will throw an exception if it somehow is handed an unauthenticated user.

This is merely one example. Keep a watch here for more information about BDD and why I'm hooked. Also, I should be putting some polish into EasySpec in the next week or two so that it's more user-friendly. If you're already using JUnit, and you want to try out BDD, take a look at EasySpec.