DanNorth.net

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.

In the meantime, Joe Ocampo has used some C#3 voodoo to create something scarily similar to rbehave for .net. He seemed to produce this in slightly less time than it took me to press “publish” in WordPress, and I have to say it looks great.

Two use cases for expressing intent

The original idea behind the JBehave story framework was that developers would write “pluggable” givens, events and outcomes to define the various scenarios that make up each story. Non-technical people would then manipulate these using desktop tools (say a graphical story builder where you drag the various components around to define your stories and scenarios).

rbehave has a different motivation, namely moving from the textual representation of a story to an executable definition in as few steps as possible. This is to allow human beings – mainly testers and business analysts – to read, write and edit executable acceptance criteria.

Liz Keogh and I are currently preparing a JBehave tutorial for OOPSLA 2007. Since JBehave was based very much on the first use case, we’ve noticed it is pretty painful to pull together a story from a standing start, without a proliferation of tiny classes emerging. I’m working on a fluent interface that is currently looking a little like this:

It’s backed by the regular JBehave classes and runs in the standard JBehave story runner.

I would love to see Morgan and Joe bring their two interpretations of acceptance-level BDD together into a single framework. It is after all just a bunch of scenario fragments playing nice together, and having the two approaches to expressing intent in the same framework means that NBehave could be both a directly-editable representation of behaviour, and at the same time the basis of a (graphical?) toolset for defining acceptance criteria in .net. Maybe even as a Visual Studio plugin.

¹ Oops – I thought it was as long ago as 2006 but Morgan put me straight.

It turns out that having a day job can play havoc with your blogging activities. I’m posting a round-up of recent activities, in no particular order, with the intention of expanding on each of these topics in the coming weeks. But we all know what happens to intentions.

This is mostly a brain dump to make me feel guilty enough to write some of it up, so feel free to skip it if you’re busy. That FaceBook page isn’t going to update itself you know.

Simplicity

At last year’s XP Day in London I got involved in a fishbowl discussion, with the likes of Kevlin Henney among others. Kevlin gets simplicity. To me it’s the holy grail of software development, and it’s all about expressing intent clearly. If you can’t make a system any simpler, then you’re done (simple, not simplistic). Likewise if you can express the intent of an application in a clearer way, you still have work to do. Erik Doernenberg and I shaped this theme into a keynote that I’ll pretend I’m going to write up at some point.

Performance tuning

A couple of years ago I did a performance tuning gig with a major retailer in the US. It was their first foray into J2EE and they were struggling with the impedence mismatch between OO and the relational database. Over the next few weeks I’ll be writing up the various approaches we took to achieve the results we got (startup time down from 10 minutes to 45 seconds, query times down from over 30 minutes to sub-second), because in the intervening period I’ve seen some of the patterns repeating themselves elsewhere.

Agile SOA

I have my “safe” topics that I’m very familiar with presenting: coaching and learning, agile and BDD, various technology topics. Last month I presented outside of my safe zone – on “SOA for Human Beings” at the ExpertZone conference in Stockholm.

SOA is not like the other kids. On one level it’s so vague it’s almost Zen: “What is SOA?” “It’s whatever you want it to be”. Secondly, it’s largely misunderstood as being a technology thing rather than a business thing. Thirdly, it’s often deliberately misrepresented as the reason you have to purchase a particular toolset.

So I stood up in front of the 17 attendees and said: we won’t be discussing code this afternoon – we might not even discuss technology. And we all had a much better afternoon because of it. There were a number of themes that came up during that session, and I’ll try to do them justice in a future article.

Builders, Commands and Fluent Interfaces

I’ve been architecting! You know, like properly designing software on a project as a tech lead. It’s great fun – I’d forgotten how much I liked it. My favourite current toys are builders – in particular fluent interfaces – and the command pattern. Suddenly my world is a simpler and happier place. Come to think of it, I’ve just rolled off a project with Patrick Kua as my tech lead. Talks a lot of sense does Patrick.

BDD in Ruby

Got rbehave out. Phew!

BDD in Java

At some point in the last couple of months, it seems we released JBehave 1.0! It’s been a labour of love, made up of infrequent short bursts of activity interspersed with long periods of day job. Lucky for me, Liz Keogh stepped up and took the reins, and with the help of some other great developers got it to 1.0. I’m very pleased with what we’ve accomplished so far, but there’s plenty more to do. In particular I want to introduce a fluent story builder to remove the need to hand-wire all the stories, and see if we can use some Java 5 goodness to simplicate things.

Real Options

No, not the things traders buy and sell. This is an overlooked branch of mathematics that explains why deferring decisions responsibly is a Good Thing, but deferring them past their “use by” date is just dumb.

My good friend Chris Matts has written an article about real options with Olav Maassen. In a demonstration of the interconnectedness of all things, there are at least two JBehave connections here. Chris was the guy who made the observation that BDD-as-TDD was just like business analysis, which in turn led to the whole story/scenario vocabulary. Olav was the first contributor to JBehave, writing a JBehave Ant task back in 2004. They are both mad as a box of badgers which means the article makes for interesting reading.

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.

Inspired by this, I wanted to find a simple and elegant way in Ruby to describe behaviour at the application level. This is a different enough problem that I couldn’t just use rspec. You can skip ahead to the Ruby code if you already know about stories and scenarios. This preamble just sets the scene for the example.

The scenarios that describe a story are made up of “steps” of Givens, Events and Outcomes. These steps can be mixed and matched in different ways to provide different sequences of events. Here is an example:

Here we have two givens: one about my savings account and the other about my cash account. We have a single event, namely transferring cash. We have two outcomes, again about the account balances.

This is typical of the scenarios in a story: they revolve around a single event (the feature itself) and prescribe different outcomes for different combinations of givens. Also, notice that the steps themselves are parameterized: the first time my savings account balance is $100, the second time it is -$20, so a story framework needs to accommodate this.

Getting it running

So then I converted the story into a rspec-like structure, preferring simple strings to method names, and do/end blocks rather than classes:

Using rspec to drive the design, I wrote a little framework that would run these scenarios, each one in its own instance of an object (so they were independent), reusing the steps as needed.

So, this only left the problem of the steps themselves. They would have to be defined somewhere else (that I hadn’t figured out yet). Then I thought: each step’s implementation should be pretty trivial, so what would happen if I put the code for each step inline in the scenario? So I ended up with this:

For this example it turns out there are no new steps to define in the second scenario, which makes it very easy to read. In general I’m finding that most of the steps get defined in the first one or two scenarios.

Implementing the code

So I saved this to a file as transfer_funds.rb and ran it, and I got two failures:

rbehave prints one character per scenario – a dot means the scenario passed, an F means it failed. At the end of the run it prints a list of the failing scenarios. So this tells me that firstly it runs (hooray!) and secondly both scenarios are failing because I’m missing an Account class. Well I don’t want a whole bunch of failing scenarios that only start to work one at a time as I implement them. That feels too much like broken windows – I’ll get too used to seeing failing scenarios and then I won’t react when workng scenarios start failing. So I introduced the idea of a “pending” scenario, by adding a pending() method:

And I got this:

The Ps represent pending scenarios, which means they aren’t working yet but they don’t count as a failure. Then I use rspec to implement an Account with a constructor that takes an initial balance, and give it a transfer_to method that moves money around. Then I remove the pending line:

Excellent! I have my first working scenario. Now I just need to add behaviour to the Account class to not transfer money it doesn’t have! But wait a minute, what about documentation? Well I added some listeners to the story runner, so when you run:

you get:

This is being generated from the same Ruby code that runs the scenarios themselves.

Next steps

You can gem install rbehave or download the source. There is a sample application (Conway’s Game of Life) in progress in the source code that shows you some of the other features rbehave supports.

rbehave was designed to play nice with other frameworks. In particular, the “world” that each scenario runs in is a module that can be mixed into any object, so you could easily use rbehave with a Rails IntegrationTest or incorporate it into your existing acceptance testing framework. It is also possible, and in fact encouraged, to use rspec in your Outcomes (balance.should == 30).

If you’re interested in using or developing rbehave, please join the mailing lists and let me know how you get on. As a parting thought, rbehave is totally compatible with jruby, so you could start writing your Java acceptance criteria in Ruby and running them in rbehave.

A number of people helped me get rbehave off the ground. In particular I have to thank Niclas Nilsson for kick-starting the whole thing, David Chelimsky (rspec lead) for his sound advice and for adding describe/it to the rspec core, Liz Keogh (jbehave lead) for demanding that steps should take parameters and not taking no for an answer. Also PragDave ran an inspiring meta-programming workshop at QCon that gave me the courage to try this stuff.

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.

I’m delivering a keynote with Martin Fowler about the gaping crevasse between what business people ask for and what technical people think they want. I’ve presented with Martin a couple of times before – at least I know I’ll only be the second loudest person in the room.

ThoughtWorks is a “platinum sponsor”, which I think means we get to buy more drinks than the other sponsors.

BDD in Ruby at ACCU, 11-14 April, Oxford

ACCU is a conference by geeks, for geeks. With its roots in the C++ community, there are lots of strange people in weird industries like embedded systems, graphics engines and writing music software. It’s a refreshing change for me, where “enterprise systems” usually means moving data from over here to over there.

I’m actually at ACCU by accident, presenting behaviour-driven development in Ruby. They haven’t noticed yet that I haven’t touched C++ in ten years, and I’m not about to tell them.

However, the ACCU folks are developing a strong liking for dynamic languages – last year Guido van Rossum, the inventor of Python, delivered a keynote, and I co-presented a session introducing Ruby and Rails. So perhaps there’s life after the standard template library after all :)

Coaching workshop and BDD session at Expo-C, 23-25 April, Gothenberg

You know the tutorial days that tend to happen either side of a conference? Well Expo-C has adopted the model of having mostly tutorial days and hardly any conference! The 23rd and 25th are tutorial days, with two speakers presenting full-day tutorials on each day (I’m on the 23rd). The middle day is made up of seminars by a number of presenters. As the only speaker who hasn’t published a book (one of the presenters, Jim Coplien, has a small library to his name), I can safely say it’s a very solid line-up. Also, it’s one of the smaller conferences so there is lots of opportunity to hang out with the presenters.

I presented a tutorial day last year around the theme of agile delivery and thoroughly enjoyed it. This year I’m doing something a bit different, focusing on “Change, Coaching and Communication”, using NLP and life coaching principles as the basis of a one day interactive workshop. As with last year, there won’t be any PowerPoint, mostly because I’m rubbish with PowerPoint.

I’ll also be presenting a behaviour-driven development session on the seminar day.

Keynote and SOA workshop at ROOTS, 25-27 April, Bergen (Norway)

I’ve not been to ROOTS before but I’ve heard good things about it. It’s a developer-centric conference and this year it features the likes of Kevlin Henney, Jim Coplien (who I’ll be racing to Norway from Expo-C) and lovely testing guru Linda Rising.

Erik Doernenberg and I are delivering a keynote on the nature of simplicity, and we’re running a three hour workshop looking at SOA for human beings.

Keynote and SOA workshop at ExpertZone, 23-25 May, Stockholm

I met Josefin Andersson, one of the organisers of ExpertZone, earlier this year and she convinced me I had to attend the ExpertZone Developer Summit in Stockholm. Since I’m scared of Josefin, I said yes. Also Microsoft’s Beat Schwegler will be there, and he rocks.

I’ll be delivering another keynote with Erik Doernenberg, based on our current pet themes of simplicity and clarity of intent (honestly, how hard can software be?), and running the workshop on SOA for humans.

I’ve been told by the Boss that I’m not allowed out of the house in June.

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.

The value of exploratory testing, on the other hand, is to try all the weird combinations that people might try – aka monkey testing – in order to break the system by using it in unlikely ways. The problem is that exploratory testing requires people, so it’s slow and expensive.

Cue RMonkey (and possibly PyMonkey and JMonkey). RMonkey augments your Ruby acceptance tests, to emulate monkey behaviour. It works like this:

Boring, old-style test:

Now we monkey it up, with the keywords usually, sometimes and rarely:

So now you have automated monkey tests. There are default probabilities for usually/sometimes/rarely (say 80%, 15%, 5%) but that is customizable:

The interesting part, of course, is to know what sequence of events leads to a test failure. A more fully-featured RMonkey would keep track of which events it executed and produce an informative narrative if things turned bad.

In the spirit of the infinite monkeys metaphor, this would prove most useful in a soak-testing scenario, whereby thousands of monkeys were hitting an application over an extended period of time. You would want to know that a) mostly it worked, and b) when it didn’t work, which sequence of events caused it to break.

Some obvious applications for RMonkey would be in driving Selenium or Watir, or using JRuby to drive JUnit, MarathonMan, WebDriver or any of the other Java testing frameworks.

The code for rmonkey.rb is simply:

So anyway, let me know if you would like to get involved in developing RMonkey. I think it’s a really appealing idea and I’d love to see someone do something with it.