Posts Tagged ‘cucumber’

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 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 ' }

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.


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.

Baldrick – a dogsbody

May 9, 2009

Ruby is an awesome language for hacking stuff together (amongst other things of course) but do you want something that takes care of more of the plumbing, especially where web feeds are involved? Baldrick will service your whims.

Check it out at Github.

The Problem

Where I used to work we used a few Delcom build lights to monitor our continuous integration build. The scripts used to run these things are great fun to write (probably why we had a few different ones floating around) but the code to monitor the RSS feed containing the build status was quite repetitive. What we really cared about was linking a change in status to a change in light colour (and behaviour), not how to pull apart the RSS for the stuff we needed.

We had modified our light scripts to make the lights flash when the build had been newly broken. Someone could then ‘claim’ the build and stop it flashing by hitting a particular web URL. We also tended to communicate such things over IRC or some other means of broadcast. I thought it would be cool if you only had to claim the build in your message and that something could pick that up and change the status of the light for you.

At the same time I was playing a lot with Sinatra and I was giddy as a schoolgirl at just how easy it was to knock out a simple web server in a few lines. The magic ability to just execute a script and have it run as a web server really ticked my fancy. I thought that I’d love to have something like Sinatra that took care of the plumbing and allowed me to easily glue events to actions.

I was also impressed with the syntax of Cucumber steps and the ability to join up a textual step with the implementation via regular expressions.

All of things came together as Baldrick:

require 'rubygems'
require 'baldrick_serve'

listen_to :feed, :at => ''

on_hearing /cup of (.*?)[\.,]/ do |beverage, order|
  puts "#{order[:who]} would like a cup of #{beverage}"  

Executing the above script will start a Baldrick server that listens to a Twitter feed for messages containing ‘cup of’. When a tweet containing a cup of something is found, the name of the tweeter and the beverage (perhaps) are spat out to the console.

How Does it Work?

Baldrick listens to a number of sources (at the moment RSS/Atom feeds and Injour statuses) for orders. The content of these sources is wrangled into a common format containing who, what, where and when.

From there its a case of hooking an order up to a task. When you define a task you give it a block to call when it is triggered. On receiving a new order, Baldrick will trigger all matching tasks. This also means that you can have orders from multiple sources triggering the same task if you so desire. Capturing groups within the regex will be passed as arguments to the block, followed by the order.

Baldrick uses the same tricks as Sinatra to allow an arbitrary script to be run as a server (the #at_exit hook).

Writing your own listeners is a snap, check out the wiki for details.

Try it out and drop me a line to tell me what you use it for.