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 TDD or BDD 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.
