A gem to assist in static program analysis of a Cucumber test suite.
Ruby Cucumber
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.



Gem Version Dependency Status

The intention of this gem is to provide a useful mechanism by which to answer all of the burning questions that one might have about their Cucumber test base.

  • Did old features get removed and leave dead step definitions behind? Or

perhaps the other way around and half of the steps in the code base are undefined?

  • Are there duplicate scenarios strewn about everywhere that only differ in

their step arguments and could be reduced into a single outline?

  • Just how many different tags are there in this thing?

These are the kinds of questions that this gem aims to make answering easy, either through directly providing the answer or by providing sufficient tools that determining the answer yourself is just a few straightforward object manipulations away.


Add this line to your application's Gemfile:

gem 'cucumber_analytics'

And then execute:

$ bundle

Or install it yourself as:

$ gem install cucumber_analytics


First things first. Load up the gem code.

require 'cucumber_analytics'

Next, let's generate a model for our Cucumber suite.

directory = CucumberAnalytics::Directory.new('path/to/the/code_directory')
world = CucumberAnalytics::World

Now it's time to take a look around and see what we can see.

all_tags = world.tags_in(directory)
puts all_tags
#=> ["@Unit", "@Fragile", "@wip", "@wip", "@Critical", "@Unit", "@wip", "@Deprecated", "@wip", "@wip"]

puts all_tags.uniq
#=> ["@Unit", "@Fragile", "@wip", "@Critical", "@Deprecated"]

wip_tags = all_tags.select{ |tag| tag == '@wip' }

puts wip_tags.count.to_f / all_tags.count
#=> 0.5

all_steps = world.steps_in(directory)
puts all_steps.collect{ |step| step.base}
#=> ["some step", "the user logs in", "the user will log in", "another step", "the user \"Bob\" logs in"]

So with a few simple commands we have discovered that there are five different tags in our codebase and that @wip tags account for half of all usages. We have also discovered that our team is creating several redundant steps that could be rewritten into a single, reusable step.

Other usages

And why stop there? There are so many other tools that can be built with a little analysis!


  1. Fork it

  2. Create your feature branch (`git checkout -b my-new-feature`)

  3. Commit your changes (`git commit -am 'Added some feature'`)

  4. Push to the branch (`git push origin my-new-feature`)

  5. Create new Pull Request

I'm always looking for new ways to poke at a testbase. Feature requests are welcome.