Testing Domain and Release Specific Features via Cucumber Tags
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.
- Person:
- Add new comment
- 293 reads
- Feed: ardes.com
- Original article


Recent comments
1 year 23 weeks ago
1 year 23 weeks ago
1 year 25 weeks ago
1 year 27 weeks ago
1 year 42 weeks ago
1 year 45 weeks ago
1 year 45 weeks ago
1 year 45 weeks ago
1 year 46 weeks ago
1 year 48 weeks ago