This rant is in response to http://robertlally.com/post/bdd-not-so-much

BDD didn’t start off as a replacement for TDD. It started off a way to better understand and explain the process of TDD. The name change as I understand it was to communicate the intent of TDD in a clearer and more direct way. You’re not writing tests for the sake of writing tests, you’re driving behaviour. Focus on the behaviour you want to achieve first and foremost. Use that behaviour as the driving force for your examples (or tests).

Corey Haines nailed it on his comment to the same post, “BDD is no longer a replacement for TDD, but, rather it is a workflow for creating a system that more closely resembles what the client is looking for.” I think two of best tools which exist to support the BDD workflow of outside-in are Cucumber and RSpec. Cucumber for higher level system behaviour and RSpec for driving lower level design.

In the article, the author criticizes the “should” language. Rather than simply scoffing at the idea of replacing “assert” with “should”, I tend to think about it in terms of natural communication. The reason I like “should” language over “assert” language is that when I’m communicating with another developer I don’t say, “assert equal one day to do things good”. That doesn’t make any sense. I say, “one day to do things to should be good”. It’s much more natural for me to write closer to the language I think and communicate than it is to translate it to assertion-speak. I want to communicate in my code more closely to how I communicate to other people.

While the term BDD is a few years old it takes a while for dialogue to happen, and understanding to occur. I’m sure a lot of people hear about BDD, read about it from Dan North’s Introducing BDD. BDD started as a way to explain and better understand BDD, but what I think was realized was that it was much more than simply TDD.

Many tools are emerging which claim to support BDD-style development. It’s important to note that BDD isn’t the tool. You can have many tools support BDD style development in different ways and to different degrees. Although a good tools makes any process easier, what makes BDD is the mindset you have and how you go about writing software. Certain tools emerged with this in mind and are thus labeled BDD tools. Cucumber, RSpec, and JBehave are some examples.

The article mistakingly sheds Cucumber in the light of solely driving the design of code and suggests its a bad tool to do that. Of course it is! It is not a tool intended to drive the design of your code from a low level. It is to communicate in plain text how the application should behave. The plain text is something that is business readable, something that adds value not at the code design level, but at a higher level: communication and understanding requirements!

Cucumber is equivalent to a high level integration test for those of you who come from a testing background. It runs the entire application (or whatever can be reached through automation, different types of systems have different limitations). It works in combination with a tool used to drive out the design of your application using lower level code examples. For example, RSpec.

The #1 output of BDD is a working application that is behaving as expected. In addition to that you have an application-level regression suite in which you can run against the code base at any time. You also end up with smaller, more focused code examples which provide regression against isolated behaviour of the system.

Combined, you end up with documentation at two critical aspects. The first is business readable scenarios that the system supports. The second is developer documentation made up of the lower level code examples. Since these are often written more clearly than assert-style syntax it’s easy to produce human readable behaviour specifications for focused pieces of behaviour. And in the end you have a repeatable process which allows you to confidently produce the working software.

I also don’t see where UML to BDD comparisons make any sense. UML is a modeling language. BDD is more of an approach or methodology. A more accurate comparison would be plain text scenarios vs. UML. Although that makes little sense as a comparison because UML is not something you can give a non technical person to write, read, and edit.

BDD by itself doesn’t fix any problems. It provides an approach which focuses on behaviour first. To me, there’s no point in building a low level library if you’re not aware what higher level problem you’re solving or objective you’re adding value to. This boils down to a person still has to “do the work” to make it successful.

At the end of the day though I cannot speak for anyone else except myself. Shifting my focus on behaviour rather than “tests” led me to write better code examples. Often times I would write less of these because I was writing better examples. It’s also helped improve communication between myself and my team, customers, and other developers. BDD may evolve into something else, or perhaps a new perspective will come around that will take the world by storm. I am all about continuous learning and improvement. And I invite any ideas Mr. Lally or anyone else brings to the table.

Also, BDD never claimed to be THE answer. Any process that claims to be THE answer will surely not be THE answer for everyone in all situations. BDD has been an answer for many people though and as of now it will continue to be an answer for me in how I work.

A good resource worth checking out for BDD, it’s philosophy, and how to apply it in practice is The RSpec Book