In the pursuit of achieving agility in the software development industry, test-driven methodologies have proven to be the cornerstone process in the last decade. Building on this momentum and with a focus on delivering reliable software solutions on time and under budget, behaviour-driven development techniques are shaping up to be the next chapter in the story of agile development.

As enterprise software developers adopt the agile mantra, they often struggle with juggling the established processes of producing traditional requirement and specification artifacts, while delivering on a rapid iteration model to meet ever-changing business needs. Keeping artifacts in textual format up-to-date with software code based on a moving target can become a point of friction and inefficiency that impedes the overall effectiveness of the agile principles. In essence, the value of enterprise software lies in solving business problems, and for this, the information and language used by the technical side and the business side has to intersect. Thus the idea of what behaviour-driven proponents call “ubiquitous language” becomes invaluable.

The inspiration behind behaviour-driven techniques lies in extending the traditional test-first development concept and marrying it with specification syntax that resembles the coveted ubiquitous language. The purpose is to enable an agile compatible “documentation” process that is executable in an automated manner - and therefore testable and maintainable in the scope of a sprint-based development framework. Some individuals in the industry call this the “just-in-time” approach to documentation that aims to keep business specification directly testable in a continuous delivery model. This is often in contrast to traditional up-front design and analysis that were the hallmark of classical waterfall methodologies.

To keep business specification relevant and reliable, the language of the requirement can be kept in a uniform semi-format format. This is the “user story” component of the requirement that can be expressed as a behaviour specification. The standard structure of such a story takes the form of defining features with:

  • a title
  • the business value narration
  • an acceptance criteria

There are various tools that can parse these structured texts and produce executable artifacts that form the basis of behaviour-driven development. The current momentum in the industry is behind Aslak Hellesøy’s Cucumber toolset that has been the flag-bearer since the earlier incarnation of the RSpec framework.

With the Cucumber framework, user stories are defined in scenarios using the Gherkin language. The language syntax keeps the specification in a format that is comprehensible and relevant to non-technical business stakeholders while making it directly usable in unit testing tools such as jUnit. Based on the core Cucumber framework capabilities, there has been further development in the area with tools such as Jnario which aims to provide a more comprehensive executable specification platform.

To demonstrate the capability of frameworks like Cucumber, here we show a sample behaviour artifact:

Even though the language used in the “feature” specification is deceptively non-technical looking, it is in fact executable and becomes the control flow of test automations.

With the setup of tools like jUnit, each of the scenarios translates into regular unit tests that start with failing test cases, and evolve into “green” passing tests. To dive into a concrete example for the above definition of behaviour, Cucumber can be initialized as:

The actual “technical” aspect of the test execution is written up as: </p>

Once the implementation matches the specification, the end-goal is to end-up with a green result that apparently executes the business produced specification:

As the original idea around test driven development matures with specialized tools to enforce software requirement integrity, business stakeholders worry less about their intentions being misunderstood. Developers, on the other hand, can obtain a level of confidence that they are delivering maximum value with their work. Nirvana is indeed within grasp!

References

Specification by Example: How Successful Teams Deliver the Right Software by: Gojko Adzic