not worth it

Jared Carroll

Behaviour-Driven Development.

The latest fad thats been around for a while but seems to be picking up a lot more lately. I messed with it and blew it off a while ago but that was a while ago, so I decided to check it out again and see what all this malarkey is about.

From behavior-driven.org

It is not too surprising that it takes apprentice TDD practitioners a while to realize that TDD is not about testing when all of the nomenclature surrounding it is described in terms of testing. The aim of BehaviourDrivenDevelopment (BDD) is to address this shortcoming. By using terminology focused on the behavioural aspects of the system rather than testing, BDD attempts to help direct developers towards a focus on the real value to be found in TDD at its most successful.

So BDD was created because it was hard to teach people that they had to write tests for code that didn’t exist yet? So all BDD does is change the vocabulary to make it seem like you’re not writing tests but “behavioural aspects” of your system?

I get how when practicing TDD your test is the first client of the code you’re about to write; essentially developing interfaces the way you’d like to use them, so it is design.

From BDD advocate Dave Astels

Does that mean you write tests? No. It means you write specifications of what your code will have to do. It means you specify the behaviour of your code ahead of time.

Ok that’s TDD to me. Tests are a way of specifying what your code will do. But now I have to refer to them as “specifications”?

Let’s look at some code now.

Here’s the popular Ruby BDD library rspec. The following code was taken off their site.

describe Account, " when first created" do

  before do
    @account = Account.new
  end

  it "should have a balance of $0" do
    @account.balance.should eql(Money.new(0, :dollars))
  end

  after do
    @account = nil
  end

end

Ok #describe is basically defining the equivalent of a TestCase in xUnit. Now #before and #after are equivalent to the #setup and #teardown methods in xUnit. And #it is the equivalent of a test method in a TestCase subclass in xUnit.

I have 2 problems with this

  1. I have to learn and start using this new language to talk about tests
  2. I have to learn a whole new syntax to write tests

I’ve used xUnit in a number of languages, its what I know. I like subclassing TestCase, getting #setup and #teardown for free and knowing that if I name my test methods starting with “test” that they’re going to get executed automatically. That is simple, obvious and what the majority of developers out there know.

I jumped on Rails because it took building web applications clearly to a new level, but to me BDD is not doing the same when it comes to testing. Somebody give me a reason to use it.