Well, it may be holiday time for many people, but it hasn’t been for us. We’ve been up to (and past) our eyeballs in work, particularly graphic design work, for the past several months. One of the items we’ve been working on is this.

The “Culture & the Mind” Project assembles individuals from a wide range of academic fields to investigate different subjects. This year the focus is “Folk Psychology”: what we, in our everyday lives, do when we attribute beliefs or desires onto other people. One of the questions the conference (and the Project in general) will attempt to do is to examine what aspects of folk psychology are innate, and what change depending upon one’s cultural upbringing.

The client had a great desire to have fun with the poster, in particular to hark back to 60s & early 70s design. I took the opportunity to quote that, but also to pay homage to one of my all-time favourite graphic designers, Steven R. Gilmore. You can only go so far quoting Jefferson Airplane & Skinny Puppy posters, though: psychedelic typography & brain imagery act as visual hooks to make the viewer take a closer look at the content of the conference.

Release versions are one way to handle your tags, but as Ian pointed out, really for most people (and perhaps me) it's excessive. I'd go further to say it's superfluous, clumsy and overly bureaucratic, all in all not very agile. Not bad for something I came up with!

While this sort of thing will take some iterating and is really down to how you arrange your work, the following simple scheme may provide a good foundation.

Tags: @stable

And that's it. Write your features, when they pass mark them as @stable, and when you want to do a regression test run it against all your @stable features.

cucumber --tags @stable -f progress features

You could even rake or alias it for added comfort.

Tags: @stable @wip @pending

In the above an untagged feature can be a work in progress, or left pending for later. While this is enough for regression testing, tagging these features as well has some workflow benefits. It's your metadata, why not use it.

Take for example the feature you quickly sketched out over lunch a week ago to flesh out later, where was it again? If it were tagged you could do a project search (TextMate) or equivalent to find the elusive text. Why waste Time looking when you can Search?™

Tag it your way

One of the nice things about these tags is you can build on this scheme quite easily, by domain, release number, external resource connectivity, or whatever you like.

This is inherently YMMV, and it should be interesting to see what other people find useful.

No, nothing to do with MS Office, promise.

This is a rehash of a conversation I had on the Cucumber mailing list / Google Group

If you are using the Paperclip plugin to handle user image submissions you may run into some head-scratching trouble when testing this with Cucumber. The following approach, while perhaps not ideal, tests the full stack, short of a browser.

The following example uses Machinist for random file selection and could be simplified to a single test image if desired.

Sample Images

Put some images into spec/fixtures directory with a common name, e.g. example1.jpg example2.gif example3.jpg and so on

Steps

My paperclip binding is called picture and it's on my service object. This is in my service steps file:

  def new_picture 
    @new_picture ||= Sham.image 
  end 

  When /^I provide an image file for "picture"$/ do 
    attach_file "service_picture", new_picture.path 
  end

And in my Sham.define block (in spec/blueprints.rb)

image do 
  images = [] 
  dirpath = File.join Rails.root, 'spec', 'fixtures' 
  Dir.new(dirpath).each { |file| images << File.new(File.join (dirpath, file)) if file =~ /^example\d/ } 
  images[rand(images.length)] 
end

Assertions?

Then /^I should see my photo$/ do 
  response.should have_selector("img[src*=''#{File.basename new_picture.path}]) 
end

or

response.body.should =~ /#{File.basename new_picture.path}/

and so on.

Note that paperclip will give you addresses resembling this:

  http://localhost:3000/system/pictures/2/index/example5.jpg?1258339851

so watch out for the secret token after the ? and don't just use == on the file path.

File Hangover

The gotcha is cleaning up the files afterwards, since we're not using the database for a file store. I took this approach (which is hacky but works, on unix) to put the paperclip test files into a different directory and delete the directory afterwards.

features/support.env

#remove paperclip files 
require 'paperclip' #make sure it's loaded, else cue intermittent weirdness 
module Paperclip::Interpolations 
  alias_method :org_attachment, :attachment 
  def attachment(att, style) 
    "CUKE/" + org_attachment(att, style) 
  end 
end 
After do 
  `rm -rf #{"#{RAILS_ROOT}/public/system/CUKE"}` 
end 
#end remove paperclip files

This wants to be an after block so that your database and file system stay in synch through your tests. Using an after all block (or equivalent) would mean the database having no pictures in it, but the directory having image files in it. While that may seem to work ok it's unnecessarily inconsistent.

While my last post highlighted spork as a way to speed up your rspec runs, unfortunately it doesn't currently seem to work out-of-the-box with cucumber. While I am sure this will be resolved in good time there is another approach to speeding up your feature runs & more besides: Tags!

Feature Spaghetti

At some point you will likely find yourself wanting to run a subset of your features rather than all of them, they may be spread across different files and directories, perhaps they're mixed within files but part of a different release. Recently I found myself having written up scenarios from an initial planning meeting which were broken up into 2 reasonably sized releases. The trouble with a straight cucumber features run is the output is a mess. It's cluttered with pending, undefined and even failing steps which you probably aren't interested in yet. Not only does this slow down the run but the terminal spam can be a real hindrance.

But wait, there's --help

cucumber --help, cukes.info and Joseph Wilk's talk at Rails Underground to the rescue!

While undefined stubs are nixed by -i or --no-snippets this absolute; you don't get the snippets you *do* want. Joseph's talk introduced me to cucumber's tagging functionality, which so far I had skirted around and avoided. While it's not yet in the Rspec Book there is a chapter on Cucumber to be added.

Meta Tags ain't just for SEO

In brief, Cucumber tags are really useful.

I broke my features up into domain tags (@services and @admin) and into releases for those written @0_2 @0_3 corresponding to my release plans.

They're easy to add: just add them to the top of your features or individual scenarios, see the wiki. If you're going to add them to an existing project this might be a big task, it can probably be automated. I found copy-paste sufficient for 10-15 feature files. If you know about it when you start out then it's painless as you just do it when you start writing the feature or allocate it to a release/iteration/etc.

Now when I'm working on a services feature I can just run pertinent features with

cucumber --tags @services -f progress features

This will also do the .-UF dance rather than printing out all the features.

Besides this I can test the features release by release, testing the current release goals. There doesn't seem to be much point checking 0.3 features when still working on 0.2.

cucumber --tags @0_2 features

No more fluff or failures for things I probably wrote earlier than I should have done.

But… But… What About The Customer?

The only downside I see to tagging is if you want to send the raw files to your customer for amendment. If you don't want them to see the tags you can try running them through cucumber and piping the result into text, or use cucumber's own file saving functionality. If your steps aren't all green you may have to fiddle with this a bit to get rid of error messages, undefined step stubs, etc.

I did something like this, as it was quicker than finding the right settings:

cucumber --quiet --tags @0_2 features > v0_2-features.txt

To diverge for a moment you're probably only interested in this if you're writing declarative features for the benefit of customer communication. If you're using cucumber purely for integration testing with "imperative" steps then you probably don't want to do this, as their eyes will glaze over. You may like to try some of the other tags shown by --help too, such as --expand for scenario outline tables.

For a comparison of imperative and declarative steps take a look at Ben Mabey's 2008 post. It's old and the technology has changed but the issue is identical. As Ben says, both approaches have their uses.

Forging Ahead

When moving forward with your project running one release at a time will become laborious. You will want to run several versions, and I don't suggest tagging features as @0_2 @0_3 etc, this would get old fast. An alternative is to run several tags at once

cucumber --tags @0_2,@0_3,@0_4 features

This sort of fiddling seems to lend itself to project-specific rake tasks, which I will be experimenting with some time soon.

Actually this doesn't work, it looks for scenarios with both tags, not either (intersection not union), so rake tasks or similar really will be handy for chaining feature runs.