SonarQube Cucumber Gherkin Plugin

Description

This plugin enables code QA analysis of Cucumber Gherkin feature files within SonarQube:

• Computes metrics: lines of code, comments lines, etc.
• Performs more than 40 checks
• Provide the ability to write your own checks

Demo

• Demo project
• Real life project: Diaspora

Usage

1. Download and install SonarQube
2. Install the Cucumber Gherkin plugin either by a direct download or through the Update Center.
3. Install your favorite analyzer (SonarQube Scanner, Maven, Ant, etc.) and analyze your code. Note that Java 8 is required to run an analysis.

Plugin versions and compatibility with SonarQube versions: http://docs.sonarqube.org/display/PLUG/Plugin+Version+Matrix

Metrics

Statements

Number of steps.

Functions

Number of scenarios and scenario outlines.

Classes

Number of features.

Available Checks

Standard

• "FIXME" tags should be handled
• "TODO" tags should be handled
• All comments should be formatted consistently
• And and But prefixes should be used instead of redundant Given/When/Then prefixes
• Byte Order Mark (BOM) should not be used for UTF-8 files
• Common Given steps should be added to Background
• Duplicated steps should be removed
• End-line characters should be consistent
• Examples data table should contain data at least two data rows
• Features should be written in the same language
• Features should have a description
• Features should have a name
• Features should have a unique name
• Features should not contain too many scenarios
• Features that do not define any scenario should be removed
• File names should comply with a naming convention
• Files should contain an empty new line at the end
• Files that do not define any feature should be removed
• Gherkin parser failure
• Given steps should follow a regular expression
• Given/When/Then steps should be defined in the right order
• Lines should not end with trailing whitespaces
• Missing data table columns should be added
• Non-Given steps should be moved out of Background
• Only tags from the whitelist should be used
• Scenarios should define at least one of each Given/When/Then step type
• Scenarios should have a name
• Scenarios should have a unique name
• Scenarios should not contain too many steps
• Scenarios that do not define any step should be removed
• Source code should be properly indented
• Spelling mistakes should be fixed
• Star (*) step prefixes should not be used
• Step sentences should not be too long
• Steps of unknown type should not be used
• Tabulation characters should not be used
• Tags should be defined at the right level
• Tags should comply with a naming convention
• Tags should not be set on Examples
• Then steps should follow a regular expression
• There should be one single When step per scenario
• Unused variables should be removed
• Useless tags should be removed
• When steps should follow a regular expression
• Wording should remain at business level

Template

• Regular expression on comment

Custom Checks

You're thinking of new valuable rules? Version 1.0 or greater provides an API to write your own custom checks. A sample plugin with detailed explanations is available here. If your custom rules may benefit the community, feel free to create a pull request in order to make the rule available in the Cucumber Gherkin plugin.

You're thinking of new rules that may benefit the community but don't have the time or the skills to write them? Feel free to create an issue for your rules to be taken under consideration.