Read Next

Test-Driven Development? Give me a break...

Update: At the bottom of this post, I've linked to two large and quite different discussions of this post, both of which are worth reading...

Update 2: If the contents of this post make you angry, okay. It was written somewhat brashly. But, if the title alone makes you angry, and you decide this is an article about "Why Testing Code Sucks" without having read it, you've missed the point. Or I explained it badly :-)

Some things programmers say can be massive red flags. When I hear someone start advocating Test-Driven Development as the One True Programming Methodology, that's a red flag, and I start to assume you're either a shitty (or inexperienced) programmer, or some kind of Agile Testing Consultant (which normally implies the former).Testing is a tool for helping you, not for using to engage in a "more pious than thou" dick-swinging my Cucumber is bigger than yours idiocy. Testing is about giving you the developer useful and quick feedback about if you're on the right path, and if you've broken something, and for warning people who come after you if they've broken something. It's not an arcane methodology that somehow has some magical "making your code better" side-effect...

The whole concept of Test-Driven Development is hocus, and embracing it as your philosophy, criminal. Instead: Developer-Driven Testing. Give yourself and your coworkers useful tools for solving problems and supporting yourselves, rather than disappearing in to some testing hell where you're doing it a certain way because you're supposed to.

Have I had experience (and much value) out of sometimes writing tests for certain problem classes before writing any code? Yes. Changes to existing functionality are often a good candidate. Small and well-defined pieces of work, or little add-ons to already tested code are another.

BDD is not automating acceptant tests

On Asier's Thoughts

Over the years I have met many who think erroneously that BDD means writing acceptance test and then automating them with a tool like cucumber.

BDD or Behaviour Driver Development was brought by Dan North as a layer on top of TDD to emphasize that we should focus on behaviour when writing our tests.

There are two types of frameworks to do so. There are the ones based on Gherkin syntax like JBehave, Cucumber or Specflow . And there are the ones based on context/specification syntax like RSpec, NSpec or MSpec.

Here two examples of both syntax:


Rendering New Theme...