Behaviour Driven Development with MSpec, SpecFlow, and Friends

Source code for this series

• github.com/AndrewKeig/devtracks

In this series

• Introduction
• Iteration 0
• Iteration 1

"Behaviour Driven Development is a 2nd generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, Agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters."
Dan North

Introduction

This is the first in a series of posts; where I implement a small web application using Behaviour Driven Development focusing on not just a specific tool; but more importantly outside-in development as a software methodology.

The title of this series of posts has been adapted stolen from the excellent book with a very similar name :) Behaviour Driven Development with RSpec, Cucumber, and Friends; go and buy this great book; when you’re done reading this.

My main aims for this project are:

• to drive the development process from the outside in
• to document the systems behaviour; so that stakeholders at various levels can understand it
• to increase flow and reduce noise during the specification process.

Behaviour driven development - an outside-in software development methodology

"Behaviour driven development is an “outside-in” methodology. It starts at the outside by identifying business outcomes, and then drills down into the feature set that will achieve those outcomes. Each feature is captured as a “story”, which defines the scope of the feature along with its acceptance criteria."
Dan North

Most projects fail due to poor or a lack of communication at some level; Behaviour Driven Development aims to bridge these communication gaps by:

• using a ubiquitous shared/common language allowing stakeholders to communicate intelligently about the domain
• driving out the real value in building a given feature
• acceptance criteria for a scenario written in the Given/When/Then grammar as a definition of done
• executable scenario and examples act as a living document of how the system works
• obtaining feedback early on in the development process; showcase features developed during a given iteration

Outside-in methodologies promote development according to stakeholder requirements in order to reduce the chance of building software that won’t be used. It improves stakeholder communication and helps developers write the minimum amount of code in order to complete a story.


Behaviour driven development for scenarios

"BDD tools come in two flavours - the "unit testing" flavour (such as NSpec and RSpec) and the higher level acceptance testing flavour such as Cucumber, JBehave or other clones of these tools. Cucumber's main goal is to involve more people and roles in acceptance testing and requirements, and make it an enjoyable (addictive) experience."
Aslak Hellesøy

At the scenario level our reasons for doing behaviour driven development are different to that at the unit level; we want to bridge the communications gap between all stake holders. We agree on a ubiquitous language and a definition of done. We write our scenarios/conditions of acceptance in conjunction with stakeholders in English. We use a tool which allows us to execute a stories scenarios/conditions of acceptance as a series of tests. A stories scenarios gives the developer a clearly defined start and end point as to where to start the development process and what is considered done for a given scenario.

I will use SpecFlow to write stories/scenarios.


Behaviour driven development for unit level specifications

"You write a specification that nails down a small aspect of behaviour in a concise, unambiguous, and executable form. It's that simple. Does that mean you write tests? No. It means you write specifications of what your code will have to do. It means you specify the behaviour of your code ahead of time."
Dave Astels

BDD at the unit level is basically about reaffirming good TDD practices; many people often refer to BDD at this level as ‘TDD done well’. TDD is not really about testing at all; its a design process; wherby the developer specifies the behaviour to be written.

At the unit level I am not concerned with writing specification in plain English; the issue is not really about communication with stakeholders outside of the development team; the reasons for doing BDD at this level are different to that at the acceptance specification level.

"While using and teaching agile practices like test-driven development (TDD) on projects in different environments, I kept coming across the same confusion and misunderstandings. Programmers wanted to know where to start, what to test and what not to test, how much to test in one go, what to call their tests, and how to understand why a test fails."
Dan North

We want to move away from the idea that we are testing the system; we are in fact documenting the system being developed by using examples; specification by example. The verification and test coverage aspects are mearly side effects of this specification process; once we have completed this specification process we will be able to verify the systems behaviour and have test coverage.

I will use MSpec to write unit level specifications


Outside-in software development cycle

The below diagram outlines the behaviour driven/outside-in approach to software development:

Iteration 0

I will discuss the requirements for this project and start defining stories and their scenarios/conditions of acceptance.