Bdd

It’s now about two weeks to OOPSLA, where Liz Keogh and I will be presenting a workshop on behaviour-driven development using JBehave. This will be along similar lines to the workshop I co-presented at RailsConf Europe last month.

So it’s that time of year again. I’ve got a number of conferences and workshops coming up, ranging over all sorts of topics. I just popped over to Martin Fowler’s site (I’m doing a talk with him this week) and noticed that he has a much more organised setup than me. All his events are in a sidebar and there is a handy link if you want more details. Another idea to go on my to-do pile.

How about that? You wait ages for a BDD framework in .net and then two come along at once! Ok, to be fair NSpec has been around for a while. However I’m talking about describing application behaviour in terms of stories and scenarios, to complement NSpec’s description of interactions between objects. (As a side note, I would love to see NSpec adopt rspec’s describe/it vocabulary rather than using contexts and specifications.)

Introducing NBehave and, well, NBehave! ¶

Morgan Persson first spoke to me about writing a .net version of JBehave at the beginning of 2007¹, so I am delighted that he has just announced his first public release of NBehave. It mixes C# and VB.net in a lovely it’s-all-about-the-CLR way. So the examples are in C#, extending VB.net framework classes.

RBehave is a framework for defining and executing application requirements. Using the vocabulary of behaviour-driven development, you define a feature in terms of a Story with Scenarios that describe how the feature behaves. Using a minimum of syntax (a few “quotes” mostly), this becomes an executable and self-describing requirements document.

BDD has been around in the Ruby world for a while now, in the form of the excellent RSpec framework, which describes the behaviour of objects at the code level. The RSpec team has focused on creating a simple, elegant syntax and playing nicely with other frameworks, in particular Rails and the Mocha mocking library.

I’ve got a number of tutorials, conference sessions and keynotes coming up over the next few months that I’m very excited about. My themes for this year are behaviour-driven development, SOA for human beings and understanding what simplicity really means. Looking at these, there is an overarching theme about getting different kinds of people talking to each other in plain English (for some value of English).

Keynote at QCon, 14-16 March, London ¶

QCon is the London version of the excellent JAOO conference in Denmark, which has become my favourite technology event of the year (apart from phone upgrade time). They attract world-class presenters to provide sessions varying from the deep technical through to people and process topics, and they’ve done the same with QCon. What’s more, they have managed to resist the lure of the sales-pitch session, which means you get to hang out with other geeks without people trying to sell you stuff. The London event is being run in conjunction with the common-sense guys at InfoQ, and I’m lucky enough to be speaking there.

So I was hanging out with a bunch of geeks in Switzerland, having one of those late night conversations, and an idea sort of emerged, and the more I thought about it, the more I liked the idea. And then I was thinking that a) I’m useless at following through on ideas and b) I would love someone to take this forwards. So here it is.

Our premise was that the value of automated testing is in its repeatability and low investment (in terms of human effort). However, running the same tests all the time just verifies that the system does a small number of well-known activities.

At a recent software architecture workshop, I was discussing the ideas behind BDD with a great group of people (more about that soon). One theme that kept coming up was the fact that I needed to write much more about BDD as an entire methodology, and to address the current perception that it is just a repackaging of test-driven development (which, to be fair, is where it started).

As I was describing the workings of BDD, I discovered that I had made the assumption that everyone knew what a Story was, in the agile sense of defining a requirement. It turns out that there’s a whole world outside of my little bubble that use all sorts of different processes for identifying and defining requirements, and in particular they don’t know what I mean by a Story, nor why they should care.

At the beginning of this year I wrote a feature article for Better Software magazine, which was published as “Behavior Modification” back in March.

The article is now available on my site. It gives an overview of behaviour-driven development, from its origins as a coaching aid for TDD through to its current form as a proven, comprehensive development approach.

Behaviour-driven development started life as an NLP exercise to stem the abuse of the word “test” in “test-driven development”. Since then it has grown into a respectable and proven agile methodology (with a small “m” of course).

Dave Astels, the award-winning author, was an early adopter of BDD and has been instrumental in raising its profile. He presented it at Canada on Rails and is taking it to JAOO and SD Best Practices. He has even presented it to Google. His Ruby BDD framework, rspec, has inspired a number of similar projects.

So, it’s taken me two years to finally get round to writing down what behaviour-driven development is all about, but I’m pleased with the result. The article has just been published in the March edition of Better Software as “Behavior ((I didn’t quite get away with the UK spelling)) Modification”.

I started talking about BDD as an evolution of TDD at the back end of 2003, and played with the idea of a BDD framework, in the form of JBehave, during 2004. I made some noise about it at the Agile Developers’ Conference in June 2004, and then at the end of the year everything went kind of quiet. That’ll teach me to have a day job.

Charles Simonyi introduced himself at a recent workshop with the words: “I was at Xerox PARC in the 70s, Microsoft in the 80s, and working on intentional software in the 90s”. He wasn’t showing off, he was just there. He pioneered WYSIWYG, created Microsoft Word, Excel and Access (as a data visualization tool), championed OO and invented metaprogramming.

What this tells me is that when Charles Simonyi thinks he is on to something, it’s probably worth listening. (Ok, I’ll forgive him szHungarian notation.) For the last 15 years, Charles has been on to intentional programming.