02.27.08
Posted in BDD, TDD at 10:38 pm by Pablosan
Lately I’ve been squeezing in work on TDD examples, learning Erlang, brushing up on Ruby and researching BDD whenever I can find a few minutes in my schedule. It just so happened that today I had a sizable block of time to focus on one thing. That one thing ended up being continued exploration into Dave Thomas’ Kata 2 (implementing a binary search) using TDD. I have tried this previously in both Java and C#, but was not satisfied with the results. A discussion and (unfortunately) interrupted pairing session with a friend of mine provided a fresh perspective.
Implementing a binary search is really a great TDD learning exercise. The hardest part for me was figuring out how to describe the desired behavior in a test – a description that would force the use of a better algorithm than just implementing a brute force, linear approach. Then it dawned on me: the key to this requirement is how many iterations it takes to find the right value and, for a binary search, that is a quantifiable number: 1 + log2(N), where N is the number of elements in the collection. If it is quantifiable, we can write an assertion. If it can be asserted, we can use TDD to drive out the implementation! I have chronicled my latest TDD approach on CodeNotes. Fair warning: it’s detailed and, therefore, long… but I’m pretty happy with it.
Who knows… after this great success, maybe I’ll go over here and kick those embers back into flame! Sudoku anyone? <evil grin>
Oh, and don’t worry: I haven’t forgotten about the BDD example in Ruby… it’s coming soon!
Permalink
02.08.08
Posted in BDD, TDD at 3:08 pm by Pablosan
In spite of all that TDD provides, there is one glaring omission: TDD is not particularly interested in business value. I’m sure that strong proponents of TDD would argue that TDD is valuable; and it is – as an engineering practice. I’m sure that those same proponents would say that TDD’s implicit improvement in design and code quality provides business value. However, it is entirely possible to follow the rules of TDD to the letter, providing beautifully designed, air-tight ,validated code, and yet provide minimal or no value to customers/stakeholders.
One might argue that, because TDD is an engineering practice it should not be required to explicitly drive business value; and that argument is not without merit. But wouldn’t it be easier to justify the use of a tool that did?! More importantly, having a tool that makes this value an assertion, rather than a happy side effect puts the emphasis where it belongs.
In my previous post you may have picked up on a theme: behavior. TDD should be about designing, describing, discovering and validating behavior. As developers practicing TDD, we are following the discipline of writing our specification iteratively… very iteratively. Focusing on behavior is what keeps us from writing an elegant system that does exactly the wrong thing. Enter Behavior-Driven Development.
BDD is not particularly new: Dave Astels wrote his excellent white paper (PDF) introducing BDD back in July of 2005, but it seems to be steadily gaining wider acceptance. When I first heard of it, only a few languages had implementations. As of today, you can find a “Spec” implementation for pretty much any major language.
The first BDD implementation was RSpec for Ruby. Excellent! Combining my new-found interest in BDD with one of my favorite programming languages should result in some interesting code examples. I’ll do my best… in my next installment!
Permalink
