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!
Interesting post. I guess the main problem would be the old garbage in – garbage out problem. Business Analysts (or someone) will always need to produce concise descriptions of what they require.
I’ve seen specifications which have said “this needs to be editable in the content manager” which is a very open statement. I love “so that” because it would definately help refine the requirement.
Yes, exacly. The So That fragment is also very useful as a support to prioritizing stories. Reasons underlying a feature request may be relatively trivial when compared to other other needs.
The M family of languages is meant for all kinds o …
I think acceptance testing and DSLs are a great fit, not least as the acceptance tests are totally customer focussed. Great stuff and be interested to follow/contribute to the project if you think you’ll be continuing with it.
Hi Colin, I totally agree with you. It’s good to see how both BDD and DDD are making a deliberate attempt to reduce the communication gap between developers and customers. Hopefully these ideas will become more mainstream in the .NET community. Incidentally, I’m going to talk about customer collaboration at Oredev next week. Thanks a lot for you offer to help on the project, by the way. I have a definite intention to develop it further and share with the community, so I’ll keep you posted. I’m sure a lot of the Oslo tooling and APIs will change fairly substantially by the time we will have a go live license, but it would be good to have something to experiment with asap.
Great to see Oslo put to use for spec languages. Although, I maintain that Dan’s syntaxes for specification often suffer from a programmer’s technology and constraint fascination syndrome. It doesn’t need to be so elaborate and constrained in terms of actual language keywords.
PS: Maybe we’ll get a chance to talk about this more at Oredev if time permits.
Hey Scott, I’m glad you liked the idea. I actually find Dan’s syntax fairly natural and I’m totally sold on bdd at the story/acceptance testing level.
We’ve been using it fairly successfully so I can’t complain at all.
It would be brilliant to meet at Oredev and share our respective experiences with it. I’ll be there all week anyway.
It’s been quite a week, certainly as far as things …
Pingback: Development in a Blink » Blog Archive » Claudio Perrone builds a BDD Grammar in Oslo’s MGrammar
Hi Claudio,
It’s really cool to see some progress on plain text BDD tools in the .NET space. FYI – Cucumber runs on IronRuby now: http://github.com/aslakhellesoy/cucumber/wikis/ironruby-and-net
Cheers from Oslo,
Aslak
wow, that’s really cool to hear. I definitely like the plain text BDD approach and cucumber is really a class framework!
Excellent work, many thanks Ill check if I can extend your grammar to unit tests
Hi Claudio
Good work!
I have created a Grammar using Oslo to generate unit tests (http://blog.stormid.com/archive/2009/02/07/45.aspx) but it is fairly domain focused at the moment – i.e. aimed at the Domain Expert. I am aiming to develop this in the future so that it is as behaviour driven as your DSL, MisBehave.
Pingback: Más ejemplos usando Oslo: Galería de ejemplos de MGrammar - Motivos de un ensamblado
Pingback: Más ejemplos usando Oslo: Galería de ejemplos de MGrammar - Miemblogs
Hope you do a video walking through this grammar and tools.
Great stuff.
Is the MG file available for download?
Hi Chris, I haven’t continued the project in the end as I was waiting for a more mature codebase. Maybe it is time to restart it. In any case, the grammar file is indicated at the end of the article, but you can find it here: http://www.claudioperrone.com/blog/files/misbehavemg.txt