CucumberAnalytics
<img src=“https://badge.fury.io/rb/cucumber_analytics.png” alt=“Gem Version” /> <img src=“https://gemnasium.com/enkessler/cucumber_analytics.png” alt=“Dependency Status” /> <img src=“https://codeclimate.com/github/enkessler/cucumber_analytics.png” />
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.
Installation
Add this line to your application’s Gemfile:
gem 'cucumber_analytics'
And then execute:
$ bundle
Or install it yourself as:
$ gem install cucumber_analytics
Usage
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.
= world.(directory)
puts
#=> ["@Unit", "@Fragile", "@wip", "@wip", "@Critical", "@Unit", "@wip", "@Deprecated", "@wip", "@wip"]
puts .uniq
#=> ["@Unit", "@Fragile", "@wip", "@Critical", "@Deprecated"]
= .select{ |tag| tag == '@wip' }
puts .count.to_f / .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
-
gist.github.com/enkessler/6408879 - Creating a step lexicon
-
gist.github.com/enkessler/6519022 - Creating unique identifiers for all test cases
And why stop there? There are so many other tools that can be built with a little analysis!
Contributing
-
Fork it
-
Create your feature branch (‘git checkout -b my-new-feature`)
-
Commit your changes (‘git commit -am ’Added some feature’‘)
-
Push to the branch (‘git push origin my-new-feature`)
-
Create new Pull Request
I’m always looking for new ways to poke at a testbase. Feature requests are welcome.