Over the years doing TDD, I’m getting increasingly concerned about the value my test fixtures are bringing to the table in terms of documenting features and expected behavior.
So far, I followed the typical pattern in TDD of creating one class (fixture) per object under test: if I have DirectoryService, I create DirectoryServiceFixture. Inside the fixture (and for the past couple years now), I’ve been pushing teams I work with to stick to a convention where every test method is prefixed with the word “Should”: this seems to be at least a bit aligned with BDD, in the sense that it causes your mind to shift into explaining what behavior you’re exercising.
But sometimes a sentence of that format doesn’t make a lot of sense, and I started to get sloppy with it. And I’m at the point where I desperately need a better way of thinking about my tests, as right now I can’t really look at a test run result and figure out what it is that the system does really, which are the scenarios and the contexts.
I like it that BDD does away with the “Test” word, which in TDD is hopelessly misleading, as mentioned by Scott Bellware, and evidenced in Joel’s awful misunderstanding of what it’s all about. Starting a presentation or discussion on TDD invariably derives into questions about the value of testing, the role of QA, and so on. I’m tired of that, as it has NOTHING to do with that.
Beware that (in my opinion) there’s nothing terrible new or revolutionary about BDD. I believe its value lies in being a form of neuro-linguistic programming (as mentioned in the NSpec page) which leads you to a different way of thinking and expressing the behavior you code. It’s mostly a way to structure and name the code you already write if you’re doing TDD, so that it has more value as a documentation tool and a communication tool with users and business stakeholders. There are, however, some BDD libraries that go to the extreme of making the code look absolutely alien. You don’t have to use them in order to apply the principles, though.
So, during my exploration of BDD, I found the following resources quite useful:
- BDD Intro by Dave Astel: the easiest to read and understand, and to map to current TDD practices, without convoluting the practice with too much language noise (unlike Dan North’s).
- Beyond TDD: BDD, by Dave Astel too. A good introductory video conference to BDD and what are some core principles, although I do not agree on the emphasis he puts in “stay away of state testing”, but other than that, pretty good. It makes me realize that something like Moq can support this style very well.
- Introducing BDD, by Dan North, who coined the term. Straightforward, easy to understand, and to the point.
- Some alternative ways of reading context/specification: a *very* helpful and dispassionate comparison of the various alternative/conventions for doing BDD. I’m kind of leaning towards the AAA syntax as it’s more familiar to what I’m doing already.
- Behavior-Driven Development: in Scott’s typical style, a rather long way to explain it all (still quite useful especially for newcomers). I don’t like the Context/Because convention, though. It doesn’t flow very well IMO.
I’m still learning about it. Will try to apply it in a concrete project and keep you posted.
Got to get my blog on a decent engine so that you can post comments! Sorry