Skip to content
A linting to for Cucumber
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.

Basic stuff: Gem Version Project License Downloads

User stuff: Cucumber Docs Yard Docs

Developer stuff: Build Status Build Status Coverage Status Maintainability Inline docs


So you have started to use Cucumber to describe your system in the abstract, natural language style of Gherkin. But wait! All of your feature files are themselves code and that means that they may need the same protection from anti-patterns as the lower level source code of your system. Enter cuke_linter.

This gem provides linting functionality for .feature files by building upon the modeling capabilities of the cuke_modeler gem. By passing models through a set of linters, reports can be generated that will inform you of potential bugs, style violations, or anything else that you can define as a problem via custom linters!


Add this line to your application's Gemfile:

gem 'cuke_linter'

And then execute:

$ bundle

Or install it yourself as:

$ gem install cuke_linter


The easiest way to use the gem is to use all of the defaults by invoking it from the command line directly.

$ cuke_linter

The linter can also be used inside of a Ruby script, like so:

require 'cuke_linter'


The linting will happen against a tree of CukeModeler models that is generated based on the current directory. You can generate your own model tree and use that instead, if desired.

Custom linters can be any object that responds to #lint and returns a collection of detected issues in the format of

 { problem: 'some linting issue',
   location: 'path/to/file:line_number' },
 { problem: 'some linting issue',
   location: 'path/to/file:line_number' },
   # etc.

Note that a linter will receive, in turn, every model in the model tree in order for it to have the chance to detect problems with it. Checking the model's class before attempting to lint it is recommended.

Custom formatters can be any object that responds to #format and takes input data in the following format:

 { linter: 'some linter name',
   problem: 'some linting issue',
   location: 'path/to/file:line_number' },
 { linter: 'some linter name',
   problem: 'some linting issue',
   location: 'path/to/file:line_number' },
   # etc.

All formatted data will be output to STDOUT unless a file location is provided as an alternative.

Below is an example of using non-default linting options.

require 'cuke_linter'

class MyCustomLinter

  def name

  def lint(model)
    return [] unless model.is_a?(CukeModeler::Scenario)

      [{ problem: 'Scenario has no name', location: "#{model.get_ancestor(:feature_file).path}:#{model.source_line}" }]


class MyCustomFormatter

  def format(linting_data)
    formatted_data = ''

    linting_data.each do |lint_item|
      formatted_data << "#{lint_item[:linter]}\n"
      formatted_data << "  #{lint_item[:problem]}\n"
      formatted_data << "    #{lint_item[:location]}\n"



linter          =
formatter       =
output_path     = "#{__dir__}/my_report.txt"
model_tree_root =

# Providing the formatter twice so that it also is printed to the console
CukeLinter.lint(linters: [linter], formatters: [[formatter], [formatter, output_path]], model_tree: model_tree_root)


Rather than using the default linters or providing a custom set of of modified linters every time linting occurs, which linters to use and any linter specific modifications can be configured in a more static manner via a configuration file or setting the configuration directly in code. See documentation for specifics.

Everything Else

For more detailed examples of usage, see the documentation here.


After checking out the repo, run bin/setup to install dependencies. Then, run bundle exec rake cuke_linter:test_everything to run the tests. You can also run bin/console for an interactive prompt that will allow you to experiment.


Bug reports and pull requests are welcome on GitHub at

  1. Fork it
  2. Create your feature branch (off of the development branch) git checkout -b my-new-feature
  3. Commit your changes git commit -am 'Add some feature'
  4. Push to the branch git push origin my-new-feature
  5. Create new Pull Request


The gem is available as open source under the terms of the MIT License.

You can’t perform that action at this time.