nick evans – devblog

The ruby/rails developer community seems to talk far more about automated developer testing than many other developer communities.  This is great.  There’s some disagreement and debate as to the level and type of testing that should be done, and that is to be expected.  There’s some debate as to which testing tools one should use, and that is also just fine and dandy (although I’ll admit that I don’t have a clue what the rspec haters are going on about).

First, anyone who claims that automated unit tests removes the need for QA testers or usability testing or any form of exploratory (manual) testing… they’re completely nuts.   Nor does it remove the need for code reviews, or refactoring, or paying attention to software design.  This seems to be main point of posts like like Hampton Hates Automated Testing and Luke Francl’s “Testing is Overated” talk at RubyFringe.  However, this is not a claim that I’ve ever heard any XPer, agilist or TDD/BDD proponent make. Instead, they’ve been saying for years now that “test driven development is not about testing”.  And talking about automated developer testing without talking about TDD/BDD seems to me like an adventure in missing the point.

If automated developer testing leads to undue confidence, then Hampton is correct: the developer’s hubris will allow more bugs to get through. In my experience, a humble/paranoid developer will benefit greatly from BDD and put out code with fewer bugs in less time. And an arrogant “my code doesn’t have bugs because of pet theory #462″ developer will eventually get themselves into trouble with or without automated tests… but the automated tests may help them dig out from it and perhaps not get into that particular brand of trouble again.

People who confuse automated developer testing with QA testing often talk about “bugs” and “reducing defect count” as if the main point of automated developer testing is to reduce bugs.  Test Driven Development is about driving yourself towards a better design (which is often also more easily testable as a happy byproduct).  This is why BDD (Behavior Driven Development) was coined: to help people grok TDD without being biased by the word “test” and some of its other connotations.  Several other terms were tried out (“eXecutable eXample Driven design” or “XXD” was my personal favorite), but BDD is the one that seemed to catch on and win out.

Also, BDD isn’t meant to be a “crutch” for “if you’re not good about thinking about programming.” It’s about giving all programmers, the so-so programmers and the guru programmers, another paradigm through which to view their code. BDD is about imagining the best possible API/interface/outcome, giving some example of how that code might work (if only the implementation were there), and then filling in the implementation until it works. And then doing it again in short incremental improvements. It’s about getting into “the flow” in minutes, instead of hours.

Yeah, those examples and their assertions also stay around until later as a regression suite. That’s nice. The better examples also hang around as documentation to future developers for how the system is expected to behave. That’s very nice. But, in my experience, they also allow me to develop better, cleaner code more quickly than otherwise… and the “tests” are both a happy byproduct and an enabler.