Time off for good behavior

Dan North has a great talk on Behavior Driven Development (BDD) posted over on InfoQ. I love the genesis behind BDD: it started with Dan being frustrated over people thinking that Test Driven Development (TDD) was about tests.

TDD is really about a way of designing and developing with a consumer/client focused bent: you start by walking in the shoes of your customer, using the software you haven't built yet. The customer in the case of TDD might be you - maybe you'll be consuming the methods of the class you're about to develop in order to develop a higher level class. But that's just a matter of scope and doesn't change the fact that you need to develop from the perspective of the person that will be using that particular piece of software.

We call these prototypical consumption exercises "writing tests", but in Dan's mind that was looking at it the wrong way - it's really focused on the behavior of your software. Thus Behavior Driven Development.

BDD has since morphed into something more than just another way of looking at TDD, providing a textual grammar (a "Domain Specific Language", albeit a small one) for specifying "given these conditions, when I execute this action, then I should have these results". Given, When, Then. Pretty simple.

"Getting the words right", Dan North said. Words being so important and so often dismissed. Getting words wrong (or at least not agreeing on or thinking about the same things when you say something) might be the single biggest source of pain in our industry (indeed, in the world).

This is one of the many reasons why I'm a big proponent of another agile discipline, Domain Driven Design (DDD), is its idea of a Ubiquitous Language.

Anyway, "Given, When, Then". Sort of acceptance criteria-like - thus BDD is often labeled an 'acceptance' testing process. I personally think that boxes into something smaller than it deserves: I think it can be used for unit testing and functional testing and integration testing too.

The idea that you can execute textual user stories is pretty powerful. Done right, it implies no more (or at least minimal) separate "requirements documents" or "test plans" or the dreaded "traceability" documents that often accompany them. That's where the BDD tools come in. And there are a lot of them: RSpec, Cucumber (for Ruby) and JBehave (Java) are probably the most popular.

But it's not about the tools, be clear, but rather the people and their interactions - having more of the latter with the former. If you haven't, take a look: there is a wide world of sports beyond your father's unit testing.

There is also a rockin' talk on "pragmatic Scala" - two of my favorite things. Scala has everything I love: a strong sense of concurrency built into the language ('actors!'), static typing but with a brevity of syntax, a functional bent ('to iterate is human, to recurse divine'), runs on the Java Virtual Machine. Great stuff. Good for you. The details of the language around how you invoke methods and what symbols you can use to name them has resulted in a lot of Scala code that's hard to read, but the idea of Scala is absolutely wonderful. I'm only just thinking in terms of its pragmatic value, with visions of Perl-like obfuscation dancing in my head. But still, check it out.