Add UniqueScenarioNamesLinter for enforcing unique scenario names#30
Add UniqueScenarioNamesLinter for enforcing unique scenario names#30leontraykov wants to merge 1 commit intoenkessler:masterfrom
Conversation
* Unique names linter * Refactoing test and fix feature name * Refactoring tests * Refactoring: spec test * Refactoring: linter rule * Refactoring: linter and tests * Fix test description * Fix problem detection within a rule * Fix: remove extra method * Refactoring by review * Fix: DRY spec test * Refactoring linter and more tests * Fixed linter * Refactoring linter and tests * Refactoring with rubocop
enkessler
left a comment
enkessler
left a comment
There was a problem hiding this comment.
I'll fiddle with the feature file this weekend and, from that, see what shakes out as needing changing in the implementation and RSpec tests. Sorry about not getting to this sooner.
| 'TestWithTooManyStepsLinter' => TestWithTooManyStepsLinter.new, | ||
| 'UniqueScenarioNamesLinter' => UniqueScenarioNamesLinter.new } |
There was a problem hiding this comment.
New linters should not be added to the default list. The list of linters that are active by default can be updated on major releases. Users can activate them explicitly if they want them sooner.
| | TestWithSetupStepAsFinalStepLinter | | ||
| | TestWithTooManyStepsLinter | | ||
|
|
||
| | UniqueScenarioNamesLinter | |
There was a problem hiding this comment.
See above comment regarding default linters.
Additionally, this test would need to be updated when new default linters are added. The Cucumber features are executable documentation for users, so it is important that they are up to date too, but the RSpec tests should cover everything on their own and prove the functionality of the gem, including the parts that aren't worth mentioning at the higher level of documentation.
| @@ -0,0 +1,189 @@ | |||
| Feature: Unique scenario names | |||
There was a problem hiding this comment.
This feature file needs another pass. Several of the example features don't demonstrate the use case that their scenario names state.
| Scenario: Linting (Bad: Duplicates of regular scenario name and one from a Rule) | ||
| Given the following feature: | ||
| """ | ||
| Feature: Sample Feature | ||
|
|
||
| Rule: Example Rule | ||
| Scenario: Duplicate Scenario Name | ||
| Given something | ||
|
|
||
| Scenario: Duplicate Scenario Name | ||
| Given something | ||
| """ |
There was a problem hiding this comment.
The 'regular' scenario here is not one. Once the Rule keyword is used, all scenarios that come after it will be considered part of that rule or part of a later Rule. Regular scenarios have to come before any usage of Rule in a feature.
2 participants
UniqueScenarioNamesLinter ensures that all scenario names within a feature file or logical block (e.g., Rule) are unique.