The value of Behavior-Driver Development and cohorts

Posted on July 24, 2011

Plenty has been written on the merits of BDD, TDD, and friends. However, I’ll address them from a different angle: in previous posts, I argued that programming languages were remarkably similar to natural languages, and a later post suggested you always focus on the outcome. It follows, then, that software can be written much like a novel, and that’s where BDD/TDD comes in.

When writing fiction, one technique is to define your protagonists’ characters, much like an actor will spend time immersing himself in his role. Once these personalities have been defined, it becomes much easier to compose dialogues, as the characters take on a life of their own and the dialogue nearly writes itself.

You’re most likely wondering how this relates to BDD. Well, much like it’s easier to write dialogue once you have well-defined characters, writing code is much easier when you’ve already defined how it should behave.

For example, in Rails you could start with a Cucumber feature, which will dictate what the views will contain and how they will behave. Then you move down into (for example) RSpec example sets that define how code should behave and interact.

Then, and only then, do you start writing the actual application code. But since you’ve already defined how it should act, there is no guesswork involved. And since you’ll use Cucumber/RSpec (or similar tools) to define the API you’re going to need to work with the code base, you’ll be describing the code you wish you had; which when implemented (and refactored) will become the code you actually DO have.

As a bonus, you’ll have a set of tests that will serve to guard against regressions, that can be used as the basis of acceptance tests, and that neatly document your code. Not only did this test base serve in creating maintainable code, it will be invaluable in maintaining agility in a growing code base: you can afford to make your code evolve quickly to implement new features without a fear of breaking things, and the tests will directly participate in reducing the time newcomers need to become familiar with the code base.


Would you like to see more Elixir content like this? Sign up to my mailing list so I can gauge how much interest there is in this type of content.