Goodbye TDD, Hello TDD …

Well a third TDD post and with mixed emotions I am here. On the one side, I have found BDD which (in my opinion) is far better then TDD.

What the h#ll is BDD you ask? Behavioral Driven Design. So what does that mean? It is development that is driven by the required behavior of your application(s). For example, if you need to write a online slot machine game, and the app you write behaves as an online slot machine game, you have successfully developed an online slot machine game. Ok, no duh! So what? How is that better then TDD where you would have written tests that would pass when you successfully written an online slot machine game?

Oooh, so go ahead and re-read that last question. Notice how it suggests that your artifact of the entire development process is a set of tests (and the implied working application), whereas the BDD version leaves you with a working application (and the implied tests).

That is the difference my friends, they are essentially the same but their terminology differs to emphasize what truly is important in the development process. The creator of BDD states that BDD is just TDD done right. And that's relevant to the effect that when using TDD it is too easy to fall into the trap of focusing on the tests. Not to imply testing isn't important, but they are a required evil in that if we never made mistakes, we would never need to write a single line of test code. As that's pretty much impossible (being human) testing and QA aims to mitigate the risk of the human factor.

So I still haven't really explained what the deal with BDD is, so here goes (and I apologize, an expert on the topic I am not.) To cite http://behaviour-driven.org/GettingTheWordsRight:

Behaviour Driven Development grew out of a thought experiment based on Neuro Linguistic Programming techniques. The idea is that the words you use influence the way you think about something.As an example, when I was first getting to grips with TDD, I was pairing with an experienced agile coach, writing little test methods, then writing the code, and generally feeling good about life. Then I went ahead and wrote some code without a test. The coach, JR, asked me why I'd written the code. I answered: “we'll need it in a minute”, to which JR replied “yes, we might”. By using the word “might”, he introduced the possibility that we might not. As it turned out, we didn't. – Dan North

As far as using it, there are a few implementations ( http://en.wikipedia.org/wiki/Behavior_driven_development) for writing tests using BDD. The most popular is rSpec ( http://rspec.info/ ) for the Ruby platform. There are severl for Java, two (mostly dead) for MS .Net Framework, and vaious others (python, PHP, scala). There is a Google Video by the rSpec creator which is quite interesting: http://video.google.com/videoplay?docid=8135690990081075324&q=behavior%20driven%20development&total=27&start=0&num=10&so=0&type=search&plindex=1

I haven't had the opportunity to do anything with BDD, nor does it look like I will with the state of BDD as it stands today. I believe what has happened is that TDD ate it and we just have to make due. The tests we write should be behaviorial based even if the syntax of the testing domain language leaves us asserting like we're writing procedural code instead of the OO stuff us enterprise type developers eat all day :-/ Please rSpec guys, port your code to .net :-))