MisBehave 0.1: Oslo’s MGrammar for BDD Executable Specifications

By November 9, 2008 December 22nd, 2015 Posts

While people are still debating about the reasons behind Oslo, the forthcoming modeling platform officially disclosed at PDC a couple of weeks ago, I thought it would be useful to share with you how, this weekend, I used MGrammar to parse plain text stories and scenarios using the Behavior-Driven Development (BDD) language originally devised by my good friend Dan North.
One of the main ideas around BDD is that we can adopt a simple language for expressing business requirements that is ubiquitous among “customers” (business analysts), testers and developers.
At the simplest level, a story may be expressed using this template (emphasis on bold is mine):

Story: <title>
As <role>
I want <feature>
So that <business reason>

In other words, a customer may write something along these lines:

Story: View music chart
As a music fan
I want to browse a list of popular songs
So that I can be motivated to buy something from the catalog

One of the immediate benefits of using this convention is that high-level requirements can be described and manipulated consistently and succinctly.
I’m particularly fond of the So that step: if well written, it often highlights the actual customer needs.
Once a need is identified, it becomes much easier for the development team to find further (and often cheaper) alternatives to the requested feature!

In the example above, “browse a list of popular songs” is the request, but being “motivated to buy something from the catalog” is the actual need. Can you imagine other features that would motivate customers to buy more? I certainly do.
The lesson here is that, almost invariably, customers request a longer antenna when they actually need a better reception. Trust me, this kind of deliberate creative thinking on finding alternatives can save you days, weeks, or even months of work.

Identifying the need is so important, in fact, that others proposed the following alternative convention, so that you can force users to put the reason of the requirement at the beginning:

In order to be motivated to buy something
As a music fan
I want to browse a list of popular songs

Are you still with me? Good. Let’s move on and discuss scenarios.
Differently from conventional, “fully dressed” use cases that I used years ago, a user story is usually written on a small card which acts as a placeholder for a subsequent conversation with the development team.
When the conversation takes place, the team would ask the customer questions such as: “what do you mean by that exactly?” To express and clarify the details of each story we write down a few scenarios:
Here, BDD can help us again with another template:

Scenario: <title>
Given <some initial context>
And <some more context>

When <some event occurs>
Then <ensure outcome>
And <some more outcome>

For example, customers, testers and/or developers could write and discuss the following:

Scenario: Browse chart
Given visitor is logged in
And visitor is on home page
When visitor clicks on chart page link
Then page should display title “Top charts”
And page should display list of top songs

These scenarios can be used as both documentation and as acceptance criteria.
If you are new to BDD, there is a little twist. Each single step in the scenario is sufficiently small to be “automated”.

Indeed, there are already several frameworks (some more mature than others) that have story runners able to relate the intention (expressed by customers) to some code (written by developers), often using a simple naming conventions (e.g. a Given step can run an equivalent Given method). The list is growing fast: JBehave, RBehave, NBehave, RSPec, Cucumber, and so on.
At InnerWorkings, we experimented for a long time with various frameworks (including our own) but we now use a Ruby-based framework called Cucumber (a brilliant rewrite of the RSpec story runner, now deprecated).
Great stuff, you will say, but I don’t want to use Ruby. Your loss, I would reply :-). We love .NET too, but we use Ruby as well.

Although I’m sure many plain-text story runners based on .NET will emerge soon (if they are not there already), this weekend I started my own pet projet. Since it uses the new language ‘M’ (MGrammar, specifically) I decided to call it MisBehave.
I haven’t bothered building a story runner yet, but you may find this picture quite interesting:



It shows Intellipad, one of the tools provided with the Oslo CTP.

On the left column, I have an instance of the language. On the central column, I have the grammar I wrote, and the third column, shows the projected tree structure. So far, I have plain text converted into a structure that will be further processed by a program. Hopefully you can see where this is going.

I haven’t tested the grammar extensively. I will clean it up, add support for scenario reuse (GivenScenario), add FIT-style tables, improve the error notifications, and refine the projections.

A few people said that writing languages is difficult. Well, it is difficult indeed if you write general purpose languages.
For simple domain-specific languages though, the task is much simpler. I wish I could say it is really trivial, but I won’t 😉

For educational purposes, you can download my grammar here (useful if you have the Oslo SDK).
Any feedback is more than welcome.
Now I’ll better stop toying around and start preparing for my presentation at Øredev!