Comments on: BDD isn’t worth it

By: sensei

sensei — Wed, 29 Apr 2009 15:44:04 +0000

I totally agree, man. The requirements need to be written somewhere, whether it's in a BDD test, or a requirements definition / technical specification document. The funny thing is, I used to write the BDD style design descriptions into simple text documents that would accompany my source code for myself when I'd code before I'd discovered BDD/TDD.

Also, what happens when we come back to the code later, and forget what our requirements were?

Sensei.

By: avdi

avdi — Tue, 28 Apr 2009 19:02:44 +0000

Unfortunately, I fear that 80% of the time people express that sentiment, they are really saying "It's too hard to get my brain into a BDD mindset, I'd rather just keep thinking of my tests as regression tests".

On a semi-related note, what do you think of the movement in some Agile circles to talk about Design By Example (DBE) instead of TDD? I almost feel like DBE expresses the intent of BDD even better than the term BDD does.

By: vertis

vertis — Tue, 28 Apr 2009 10:34:28 +0000

This is something that I've been considering while writing test cases with shoulda, all of the test frameworks are similiar, in so much as they're all unit tests. What matters is that TDD doesn't necessarily mandate writing the test first or even what you should write in the test. You have tools like rcov & heckle that make sure you are testing your code, but what you have with TDD is retrospective of the initial work.

I helps you prevent breakages moving from version to version, etc, but it doesn't help you do the design right in the first place. BDD with rspec/cucumber is the opposite, you sit down and you scope out HOW it should work in the form of tests(specs) and then write code that conforms to those outlines.

I would argue that BDD becomes TDD as soon as the design is done. After that point you're using your BDD framework (e.g. rspec) to do TDD.