You may have heard about test-driven development, or TDD. The idea is that you write all your tests, run them, watch them fail, and then write code that makes all the tests pass. There are many advantages to this approach. I have done projects with and without TDD, and the projects that used TDD came together more quickly and were more reliable. Yet myself and my teams still did not use TDD consitently. Why? Because it is a drag. Everyone knows that it is a better way to build a system, yet as you slog through the test writing, it is hard to convince yourself of that.

Along comes behavior-driven development, or BDD. Now instead of writing tests that fail (which is really pretty negative and depressing) you describe the desired behavior of your objects, and mark the implementation as pending. Since you probably have to document your objects anyway , it does not feel like a waste of time. And writing BDD tests is just more fun than traditional unit tests.

Some of the critics of BDD say it is just TDD with different terminologies and syntaxes. That’s more or less true. But anything that “tricks” developers into doing the right thing is worth paying attention to. Furthemore, you are likely to get better tests with more coverage, because the BDD frameworks make you want to write tests for everything.

Want to try out BDD? There are implementations for every major language. If you are using Ruby, check out the awesome RSpec framework. For other languages, see this page.

If you have tried TDD before and given up on it, give BDD a try. You will stick with it this time!