In this blog so far, I haven’t made a habit of singling out other blog posts, although every week I read posts that deserve comment.

But I feel compelled to point to Peter Williams’ “Mocking” post that I read this morning, because it shines a light on an area of software development that is relatively new and still somewhat nebulous, both for experienced test driven developers (TDD) and those who are not “test infected”: behavior driven development (BDD).

“Mocking” epitomizes what a good post should be; Peter writes from hard won experience, presenting a balanced view of both the pros and cons of BDD he has observed. The post is full of not-so-common common sense, and he succinctly summarizes the basic truths that have been discovered over time by the TDD culture, particularly, the link between testing and design. This link is something that TDDers come to understand pretty quickly I think, but unfortunately, its an important point that is hard to appreciate until you actually apply TDD in your work.

Peter also nicely summarizes the various purposes served by testing and frames the TDD vs. BDD discussion in terms of optimizing trade-offs among these purposes. Of particular interest to me was how he positioned functional/acceptance testing as a way to address some shortcomings he has observed with BDD style testing.

Because of my TDD background and the relative newness of BDD, I have had a hard time understanding the benefits of BDD, especially in relation to TDD. If you have had a similar difficulty, this post is a must-read. I also highly recommend Mocks Aren’t Stubs by Marting Fowler which also clarifies the differences between TDD and BDD.

Update
I just saw this on DZone, which also looks interesting, especially as a follow-up to the “Mocking” post mentioned above:

• R-S-P-E-C 4-ME

.