I sat down last week to start a new project with ASP.NET MVC 2. The project was something simple in theory, but I knew the details would get me. I have been a long time advocate of Test Driven Development or TDD, but wanted to give this thing called Behavior Driven Development (BDD) a chance (again). A long time ago I explored BDD frameworks but I was always too busy to really give it the chance to sink in to my brain. This time I decided to buckle down and give it an honest go. Below are the things I’ve noticed with my first serious week experience with BDD.

Tests Take Longer To Think Up

This might sound like a bad thing, but it isn’t.  Before with TDD, I would pick a service and then write a test for a particular method within that service. My tests would come together pretty fast, but there was always a disconnect. Why did I choose to write the test first and that way? The answer to these questions would be in my head, but other developers can’t see into my head. Think of it this way; if TDD helped me figure out the WHAT, BDD helped me clear up the WHY. My BDD tests are a lot more specific about their intention and the context the test exists in. If another developer would come along and read my specifications, they can read them and know what the WHY behind my code is.

All My Knowledge Still Applies

Although I am taking a different approach to developing an application, I still use all the knowledge I have accumulated up to the point I turned to BDD. I am still using NUnit, IoC, Moq, Domain Driven Design, and all my other conventions. With BDD, you are simply just reframing your existing tools and skills and not changing them. When I first started, I felt like I was entering a new arena, but it soon became comfortable when I noticed it is not a lot is different.

I Totally Need A Context

A BDD test is called a Story, and each story has scenarios. Scenarios follows the form of “Given X When Y Then Z”.  With most frameworks I’ve looked at, each part of the scenario is an independent method that is executed. So to link the scenario up you need a context that is passed to each step of the scenario. Without a context you’ll find it really hard to link each aspect of the scenario.

Lambdas Are My Friends

BDD thrives in the new .NET 3.5 and 4 frameworks. If it wasn’t for lambda expressions my tests would be a lot less readable and a lot longer (my fingers would fall off).

People Might Think I’m Crazy

I find myself talking out loud, trying to find the best phrasing for scenarios. People might look at you weird if you do this in an office environment, but the more you talk to yourself the more fluid scenario creation will be.

It All Comes Together

I’m amazed at how stuff just works the first time when it’s all wired up. I know that’s the point of writing specs and passing them, but it really is amazing. If something fails in my application it is usually because I forgot to register a type in my IoC container or I mistyped something in the View. That saves me tons of frustration, and I like it.

Conclusion

Is BDD better than TDD? I feel that both TDD and BDD are two sides of the same coin. My main goal should be to test functionality and both approaches do that. That being said, I feel that BDD has made my development process a lot more thoughtful. Is BDD the silver bullet? Not even close, at the end of the day you, the developer, are responsible for the quality of your code. Using a process like BDD or TDD challenges my discipline, and if I don’t have it then any approach to software development will be filled with frustration and hurt. On the bright side, I feel it is never to late to learn something new and improve my skills, so give something new a chance and happy coding.