Posts Tagged ‘bdd’

Bumps – remote features for Cucumber

July 20, 2009

Bumps is a remote feature management extension for Cucumber. It allows you to pull in feature content from another location prior to performing a Cucumber run and then post the results after. What this means is that features no longer have to live in plain text files within your project and that you have an easier way to notify another system of the results of a run.

Check it out on Github

… or read on if you’d like the lowdown on why it came into existence.

The Problem

We had a stab at BDD once. Although we learned a lot and made some good progress, there were a few points of friction. We were all editing feature content in the usual way and checking changes into the version control system. Developers were happy with this but the business analyst was not. He wanted bells, whistles, rounded corners. Sweet lullabies to soothe him as he tinkered with yet another login feature.

As somebody who messes around with text files all day, I thought “surely it isn’t that hard”. Unfortunately, something doesn’t have to be that hard to be discouraging.

Demands for more usable tools are perfectly reasonable. The tools we were using were second nature for developers but this was not the case for just about everyone else. I don’t blame any business analyst or tester for not wanting to edit plain text files and mess around with a version control system.

BDD is meant to be something that benefits and is owned by the whole team including the customer, their proxies and testers.

More accessible tools need to be created if BDD is to gain wider acceptance across the whole team and in general. Members of the team who are not developers should not have to stretch so far to use BDD tools. Given an absence of appealing tools for everyone, more teams will toss BDD into the too-hard basket.

Another problem is the visibility of feature status. I can imagine how writing features could seem like tossing scraps of paper into a black hole to some if they do not actively check (or are even aware of) feature reports. It seems that developers get to have most of the fun of seeing a feature executed and passing. Anyone editing features as text files that doesn’t actively run them probably doesn’t get this warm and fuzzy feeling.

Features are living things and should appear that way to everyone. They are constantly passing, failing or sitting there pending as the code is in flux. A nicely formatted HTML report is a great way to show the status of features but it is detatched from the original feature. Having a single place to edit feature content and show feature status should make it easier to follow that status. Imagine being able to edit a feature or scenario and then a few seconds later, see its status appear. Tools like FitNesse are moving in the right direction of adding this sort of visibility.

So the these two problems are:

  • how can we edit features in a more accessible way but still allow them to be executed easily?
  • how do we make the status of features more visible and tied to the features themselves?

Google Wave

Unless you’ve rejected technology and opted to live in a cave for the past few months (tempting at times), you have probably heard of Google Wave.

Wave is an ambitious new platform for collaboration and information exchange that has many dribbling in anticipation. Watch the video if you haven’t already. Wave looked to me like a pretty intuitive fit for some of the problems we had been facing earlier.

A wave (with the right extensions) is potentially capable of the following:

  • allow the entire team to edit and collaborate on feature descriptions
  • reflect the status of the last test run, showing exactly which features, scenarios and steps passed, failed or were pending
  • automatically run a feature as soon as it has been edited

So, Wave looks pretty cool. It is still pretty raw but a general release is on the horizon. How do we get it working with our current BDD tools?

Bumps

Bumps is only a small piece in the overall puzzle of providing better way to collaborate in BDD. It is an attempt to adapt Cucumber for this purpose.

There were already a few different Cucumber extensions out there like Pickler and Remote Feature but I wanted to make something a little more generic that would work after adding just two extra lines of code. And here they are:

  require 'bumps'
  Bumps.configure{ use_server 'http://myserver.com }

All you need to do is place them inside of your env.rb or other file loaded by Cucumber and then kick off a run as normal. Providing that the feature argument you gave it was a directory and there is a server running at the address configured, Bumps will

  • pull feature files across HTTP and write them to the directory
  • run Cucumber as normal
  • push the results of the run across HTTP

At the moment Bumps is quite generic. This means that you should be able to easily use it with JIRA or other systems providing that you build a compliant server. It was designed to be used with Google Wave and will most likely evolve in line with that technology. I haven’t even started digging into Wave development in earnest yet. I’m expecting that Bumps will change significantly once I do. I’m hoping that it will also benefit from others doing the same.

Next?

The next step is to try and develop some tools that make use of Wave and see just what can be achieved. Maybe it won’t be all that great, maybe it will.

With all this talk of shiny things I feel that I must also drag out the well-worn phrase, no silver bullet. Even the most awesome of tools will never guarantee your success, only help minimise the chance of failure. Nothing is a substitute for a team that knows how to communicate and collaborate effectively.

I would rather have a team chiseling features into a stone tablet if it meant that they actually talked more about what the system should do.

That aside, having nice tools can’t hurt your chances.