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
sudo gem install mattwynne-cucover --source http://gems.github.com
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 cucover.data file):
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?
- Google Testar
- Contact: Misha Dmitriev
- Clover test optimization
- Matt Wynne
- Joseph Wilk