Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Lazy coverage-aware running of Cucumber acceptance tests
Ruby JavaScript
Branch: master
Failed to load latest commit information.
bin Going on a mad refactoring tangent, adding a coverage-of feature to r…
features Add command line help
lib Add command line help
spec Refactoring and cleaning up
tmp Added logging
.gitignore Added logging
Licence.txt Add License.
README.markdown words
Rakefile Correct bad gem dependencies. Also add myself to aithers
VERSION Version bump to 0.1.3
cucover.gemspec catch bumped version
cucumber.yml Cope with Rcov giving different lines for coverage with Ruby 1.8 and 1.9



Cucover is a thin wrapper for Cucumber which makes it lazy.

Question: What does it mean for Cucumber to be lazy?

Answer: It will only run a scenario if it needs to.

How does it decide whether it needs to run a scenario? Every time you run a feature using Cucover, it watches the code in your application that is executed, and remembers. The next time you run Cucover, it skips a scenario if the source files (or the feature itself) have not been changed since it was last run.


  • Within a feature, Cucover will only re-run the Scenarios that have been affected by your changes
  • Uses RCov to map features to covered source files
  • Patches Rails to also map scenarios to covered .erb view templates
  • Shows skipped Scenarios, for confidence
  • Re-runs failing features, even when nothing has changed, for that good old red-bar feel.
  • Allows you to see which lines of a source file are tested by which scenarios

Installation and Usage

sudo gem install mattwynne-cucover --source

To run your features lazily, use the cucover binary instead of cucumber:

cucover -- features/lamb_chops.feature

To see what Cucover has already recorded (in the file):

cucover --show-recordings

To find out which tests cover which lines of a given source file:

cucover --coverage_of path/to/some_source_file.rb


  • Anything that runs out of process will not be covered, and therefore cannot trigger a re-run, so if you use Cucumber to drive Selenium, for example, you're out of luck.
  • This is very new and experimental. There may be bugs. Feedback is welcome via github messages.


  • Proper args parsing and command-line help
  • Work on a way to include coverage from out-of-process ruby code run during a test
  • Speed up the whole thing by only writing the recordings to disk when the process exits
  • Run code coverage and remove any slop following refactoring
  • Speed up the Rails test - maybe strip some guff out of the environment load?

Similar 'Selective Testing' Tools


  • Matt Wynne
  • Joseph Wilk
Something went wrong with that request. Please try again.