High Ceremony Testing

You know what gets my hackles up? Blog posts like this
one, where
the author not only misunderstands Behavior-Driven Development, but says we
shouldn’t use it for startups because it’s “restrictive”, and because it implies
some ceremony to testing our software. Saying BDD is ceremonial, at this point, is like saying that OO is
ceremonial, or design patterns are ceremonial: It’s the kind of thing you do to
make excuses for why your software isn’t as good as it could be.

We’re writing software, here, not haiku or sonnets. We’re not placing limits on
ourselves to spur creative juices. We don’t write tests to place barriers
between us and our products. We write them because it lets us write good
software. The questions BDD
makes you ask of your code aren’t supposed to restrict you, they’re supposed to
guide you.

The point is that if you eschew BDD out of some rejection of “ceremony”, you’re really
missing the benefit of test-driving your code to begin with. A test written in a
BDD style asks you what you
want your code to accomplish. Your code has to answer that question, and if it
can’t answer that question, it’s not good code. It’s the exact same question you
should be asking your business. If you can’t answer that, why are you in
business? If your business moves so fast that you can’t BDD your solution, either your business is on far too
unstable ground or you’re not actually a good programmer.

You shouldn’t write tests because you want people to see you writing tests. You
shouldn’t practice TDDorBDD because you want to adhere to a
fad. You shouldn’t write tests only when it’s convenient. It’s not “ceremony” to
do things the right way.