cuke_linter 1.3.0 → 1.4.0

data/testing/cucumber/features/configuration/using_configurations.feature

@@ -1,41 +1,41 @@
-Feature: Using a configuration
-
-  Configuration can be done during a script or through a configuration file. This file can be explicitly
-  provided or a default configuration file will be used.
-
-
-  Scenario: Providing a configuration directly
-    Given a linter registered as "SomeLinter"
-    When the following code is used:
-      """
-      CukeLinter.load_configuration(config: { 'SomeLinter' => { 'Enabled' => false } })
-      """
-    Then the linter "SomeLinter" is no longer registered
-
-  Scenario: Loading a configuration from a file
-    Given a linter registered as "SomeLinter"
-    And the following configuration file "my_config.file":
-      """
-      SomeLinter:
-        Enabled: false
-      """
-    When the following code is used:
-      """
-      CukeLinter.load_configuration(config_file_path: '<path_to>/my_config.file')
-      """
-    Then the linter "SomeLinter" is no longer registered
-
-  Scenario: Using the default configuration file
-    Given a directory "test_directory"
-    And the following configuration file "test_directory/.cuke_linter":
-      """
-      SomeLinter:
-        Enabled: false
-      """
-    And a linter registered as "SomeLinter"
-    When "test_directory" is the current directory
-    And the following code is used:
-      """
-      CukeLinter.load_configuration
-      """
-    Then the linter "SomeLinter" is no longer registered
+Feature: Using a configuration
+
+  Configuration can be done during a script or through a configuration file. This file can be explicitly
+  provided or a default configuration file will be used.
+
+
+  Scenario: Providing a configuration directly
+    Given a linter registered as "SomeLinter"
+    When the following code is used:
+      """
+      CukeLinter.load_configuration(config: { 'SomeLinter' => { 'Enabled' => false } })
+      """
+    Then the linter "SomeLinter" is no longer registered
+
+  Scenario: Loading a configuration from a file
+    Given a linter registered as "SomeLinter"
+    And the following configuration file "my_config.file":
+      """
+      SomeLinter:
+        Enabled: false
+      """
+    When the following code is used:
+      """
+      CukeLinter.load_configuration(config_file_path: '<path_to>/my_config.file')
+      """
+    Then the linter "SomeLinter" is no longer registered
+
+  Scenario: Using the default configuration file
+    Given a directory "test_directory"
+    And the following configuration file "test_directory/.cuke_linter":
+      """
+      SomeLinter:
+        Enabled: false
+      """
+    And a linter registered as "SomeLinter"
+    When "test_directory" is the current directory
+    And the following code is used:
+      """
+      CukeLinter.load_configuration
+      """
+    Then the linter "SomeLinter" is no longer registered

data/testing/cucumber/features/custom_linters.feature

@@ -1,56 +1,56 @@
-Feature: Custom linters
-
-  In addition to the linters provided by CukeLinter, custom linters can be used. A linter is
-  essentially any object that provides a few needed methods. In order to simplify the creation
-  of custom linters, a base linter class is available that provides these needed methods.
-
-
-  Scenario: Creating a custom linter object
-    Given the following custom linter object:
-      """
-      custom_name    = 'MyCustomLinter'
-      custom_message = 'My custom message'
-      custom_rule    = lambda do |model|
-                         # Your logic here, return true for a problem and false for not problem
-                         true
-                       end
-
-      @linter = CukeLinter::Linter.new(name: custom_name,
-                                       message: custom_message,
-                                       rule: custom_rule)
-      """
-    And a model to lint
-    When the model is linted
-    Then an error is reported:
-      | linter         | problem           | location                           |
-      | MyCustomLinter | My custom message | <path_to_file>:<model_line_number> |
-
-  Scenario: Creating a custom linter class
-    Given the following custom linter class:
-      """
-      class MyCustomLinter < CukeLinter::Linter
-
-        def name
-          'MyCustomLinter'
-        end
-
-        def message
-          'My custom message'
-        end
-
-        def rule(model)
-          # Your logic here, return true for a problem and false for not problem
-          true
-        end
-
-      end
-      """
-    And the following code is used:
-      """
-      @linter = MyCustomLinter.new
-      """
-    And a model to lint
-    When the model is linted
-    Then an error is reported:
-      | linter         | problem           | location                           |
-      | MyCustomLinter | My custom message | <path_to_file>:<model_line_number> |
+Feature: Custom linters
+
+  In addition to the linters provided by CukeLinter, custom linters can be used. A linter is
+  essentially any object that provides a few needed methods. In order to simplify the creation
+  of custom linters, a base linter class is available that provides these needed methods.
+
+
+  Scenario: Creating a custom linter object
+    Given the following custom linter object:
+      """
+      custom_name    = 'MyCustomLinter'
+      custom_message = 'My custom message'
+      custom_rule    = lambda do |model|
+                         # Your logic here, return true for a problem and false for not problem
+                         true
+                       end
+
+      @linter = CukeLinter::Linter.new(name: custom_name,
+                                       message: custom_message,
+                                       rule: custom_rule)
+      """
+    And a model to lint
+    When the model is linted
+    Then an error is reported:
+      | linter         | problem           | location                           |
+      | MyCustomLinter | My custom message | <path_to_file>:<model_line_number> |
+
+  Scenario: Creating a custom linter class
+    Given the following custom linter class:
+      """
+      class MyCustomLinter < CukeLinter::Linter
+
+        def name
+          'MyCustomLinter'
+        end
+
+        def message
+          'My custom message'
+        end
+
+        def rule(model)
+          # Your logic here, return true for a problem and false for not problem
+          true
+        end
+
+      end
+      """
+    And the following code is used:
+      """
+      @linter = MyCustomLinter.new
+      """
+    And a model to lint
+    When the model is linted
+    Then an error is reported:
+      | linter         | problem           | location                           |
+      | MyCustomLinter | My custom message | <path_to_file>:<model_line_number> |

data/testing/cucumber/features/default_linters.feature

@@ -1,57 +1,57 @@
-Feature: Default Linters
-
-  As a user of cuke_linter
-  I want a default set of linters to be used
-  So that I don't have to specifically include every linter
-
-
-  Scenario: Using the default linters
-    Given no other linters have been registered or unregistered
-    Then the following linters are registered by default
-      | BackgroundDoesMoreThanSetupLinter            |
-      | ElementWithCommonTagsLinter                  |
-      | ElementWithDuplicateTagsLinter               |
-      | ElementWithTooManyTagsLinter                 |
-      | ExampleWithoutNameLinter                     |
-      | FeatureFileWithInvalidNameLinter             |
-      | FeatureFileWithMismatchedNameLinter          |
-      | FeatureWithTooManyDifferentTagsLinter        |
-      | FeatureWithoutDescriptionLinter              |
-      | FeatureWithoutNameLinter                     |
-      | FeatureWithoutScenariosLinter                |
-      | OutlineWithSingleExampleRowLinter            |
-      | SingleTestBackgroundLinter                   |
-      | StepWithEndPeriodLinter                      |
-      | StepWithTooManyCharactersLinter              |
-      | TestShouldUseBackgroundLinter                |
-      | TestWithActionStepAsFinalStepLinter          |
-      | TestWithBadNameLinter                        |
-      | TestWithNoActionStepLinter                   |
-      | TestWithNoNameLinter                         |
-      | TestWithNoVerificationStepLinter             |
-      | TestWithSetupStepAfterActionStepLinter       |
-      | TestWithSetupStepAfterVerificationStepLinter |
-      | TestWithSetupStepAsFinalStepLinter           |
-      | TestWithTooManyStepsLinter                   |
-
-
-  Scenario: Registering new linters
-    Given no linters are currently registered
-    When the following code is used:
-      """
-      linter_object = <code_to_generate_a_new_linter_instance>
-
-      CukeLinter.register_linter(linter: linter_object,  name: 'MyNewLinter')
-      """
-    Then the following linters are registered
-      | MyNewLinter |
-
-  Scenario: Unregistering existing linters
-    Given a linter registered as "SomeLinter"
-    When the following code is used:
-      """
-      linter_object = <code_to_generate_a_new_linter_instance>
-
-      CukeLinter.unregister_linter('SomeLinter')
-      """
-    Then the linter "SomeLinter" is no longer registered
+Feature: Default Linters
+
+  As a user of cuke_linter
+  I want a default set of linters to be used
+  So that I don't have to specifically include every linter
+
+
+  Scenario: Using the default linters
+    Given no other linters have been registered or unregistered
+    Then the following linters are registered by default
+      | BackgroundDoesMoreThanSetupLinter            |
+      | ElementWithCommonTagsLinter                  |
+      | ElementWithDuplicateTagsLinter               |
+      | ElementWithTooManyTagsLinter                 |
+      | ExampleWithoutNameLinter                     |
+      | FeatureFileWithInvalidNameLinter             |
+      | FeatureFileWithMismatchedNameLinter          |
+      | FeatureWithTooManyDifferentTagsLinter        |
+      | FeatureWithoutDescriptionLinter              |
+      | FeatureWithoutNameLinter                     |
+      | FeatureWithoutScenariosLinter                |
+      | OutlineWithSingleExampleRowLinter            |
+      | SingleTestBackgroundLinter                   |
+      | StepWithEndPeriodLinter                      |
+      | StepWithTooManyCharactersLinter              |
+      | TestShouldUseBackgroundLinter                |
+      | TestWithActionStepAsFinalStepLinter          |
+      | TestWithBadNameLinter                        |
+      | TestWithNoActionStepLinter                   |
+      | TestWithNoNameLinter                         |
+      | TestWithNoVerificationStepLinter             |
+      | TestWithSetupStepAfterActionStepLinter       |
+      | TestWithSetupStepAfterVerificationStepLinter |
+      | TestWithSetupStepAsFinalStepLinter           |
+      | TestWithTooManyStepsLinter                   |
+
+
+  Scenario: Registering new linters
+    Given no linters are currently registered
+    When the following code is used:
+      """
+      linter_object = <code_to_generate_a_new_linter_instance>
+
+      CukeLinter.register_linter(linter: linter_object,  name: 'MyNewLinter')
+      """
+    Then the following linters are registered
+      | MyNewLinter |
+
+  Scenario: Unregistering existing linters
+    Given a linter registered as "SomeLinter"
+    When the following code is used:
+      """
+      linter_object = <code_to_generate_a_new_linter_instance>
+
+      CukeLinter.unregister_linter('SomeLinter')
+      """
+    Then the linter "SomeLinter" is no longer registered

data/testing/cucumber/features/formatters/pretty_formatter.feature

@@ -1,26 +1,26 @@
-Feature: Pretty formatter
-
-  The 'pretty' formatter is a basic text formatter that organizes problems into something simple and human readable.
-
-  Scenario: Formatting linter data
-    Given the following linter data:
-      | linter name     | problem             | location             |
-      | SomeLinter      | Some problem        | path/to/the_file:1   |
-      | SomeOtherLinter | Some other problem  | path/to/the_file:33  |
-      | SomeOtherLinter | Some other problem  | path/to/the_file:101 |
-      | SomeOtherLinter | Yet another problem | path/to/the_file:55  |
-    When it is formatted by the "pretty" formatter
-    Then the resulting output is the following:
-      """
-      SomeLinter
-        Some problem
-          path/to/the_file:1
-      SomeOtherLinter
-        Some other problem
-          path/to/the_file:33
-          path/to/the_file:101
-        Yet another problem
-          path/to/the_file:55
-
-      4 issues found
-      """
+Feature: Pretty formatter
+
+  The 'pretty' formatter is a basic text formatter that organizes problems into something simple and human readable.
+
+  Scenario: Formatting linter data
+    Given the following linter data:
+      | linter name     | problem             | location             |
+      | SomeLinter      | Some problem        | path/to/the_file:1   |
+      | SomeOtherLinter | Some other problem  | path/to/the_file:33  |
+      | SomeOtherLinter | Some other problem  | path/to/the_file:101 |
+      | SomeOtherLinter | Yet another problem | path/to/the_file:55  |
+    When it is formatted by the "pretty" formatter
+    Then the resulting output is the following:
+      """
+      SomeLinter
+        Some problem
+          path/to/the_file:1
+      SomeOtherLinter
+        Some other problem
+          path/to/the_file:33
+          path/to/the_file:101
+        Yet another problem
+          path/to/the_file:55
+
+      4 issues found
+      """

data/testing/cucumber/features/linters/background_does_more_than_setup.feature

@@ -1,84 +1,84 @@
-Feature: Background does more than setup linter
-
-  As a reader of documentation
-  I want to backgrounds to not contain actions or verifications
-  So that what is being demonstrated in individual use cases is clear
-
-
-  Scenario: Linting backgrounds with action steps
-    Given a linter for backgrounds that do more than setup
-    And the following feature:
-      """
-      Feature:
-
-        Background:
-          Given some setup
-          When some action
-      """
-    When it is linted
-    Then an error is reported:
-      | linter                            | problem                        | location         |
-      | BackgroundDoesMoreThanSetupLinter | Background has non-setup steps | <path_to_file>:3 |
-
-  Scenario: Linting backgrounds with verification steps
-    Given a linter for backgrounds that do more than setup
-    And the following feature:
-      """
-      Feature:
-
-        Background:
-          Given some setup
-          Then some verification
-      """
-    When it is linted
-    Then an error is reported:
-      | linter                            | problem                        | location         |
-      | BackgroundDoesMoreThanSetupLinter | Background has non-setup steps | <path_to_file>:3 |
-
-  Scenario: Linting backgrounds with only setup steps
-    Given a linter for backgrounds that do more than setup
-    And the following feature:
-      """
-      Feature:
-
-        Background:
-          Given some setup
-          And some more setup
-          * this is also setup
-      """
-    When it is linted
-    Then no error is reported
-
-  Scenario Outline: Configuration of keywords for different dialect
-    Given a linter for backgrounds that do more than setup has been registered
-    And the following configuration file:
-      """
-      BackgroundDoesMoreThanSetupLinter:
-        Given:
-          - Dado
-        When:
-          - Quando
-        Then:
-          - Então
-          - Entao
-      """
-    And the following feature:
-      """
-      # language:pt
-      Funcionalidade: Feature name
-
-        Contexto: A Background in pt dialect
-          Dado some setup in pt dialect
-          <step>
-      """
-    When the configuration file is loaded
-    And it is linted
-    Then an error is reported:
-      | linter                            | problem                        | location         |
-      | BackgroundDoesMoreThanSetupLinter | Background has non-setup steps | <path_to_file>:4 |
-
-    Examples:
-      | step                                          |
-      | Quando this is an action in pt dialect        |
-      | Então this is a validation in pt dialect      |
-      | Entao this is also a validation in pt dialect |
+Feature: Background does more than setup linter
+
+  As a reader of documentation
+  I want to backgrounds to not contain actions or verifications
+  So that what is being demonstrated in individual use cases is clear
+
+
+  Scenario: Linting backgrounds with action steps
+    Given a linter for backgrounds that do more than setup
+    And the following feature:
+      """
+      Feature:
+
+        Background:
+          Given some setup
+          When some action
+      """
+    When it is linted
+    Then an error is reported:
+      | linter                            | problem                        | location         |
+      | BackgroundDoesMoreThanSetupLinter | Background has non-setup steps | <path_to_file>:3 |
+
+  Scenario: Linting backgrounds with verification steps
+    Given a linter for backgrounds that do more than setup
+    And the following feature:
+      """
+      Feature:
+
+        Background:
+          Given some setup
+          Then some verification
+      """
+    When it is linted
+    Then an error is reported:
+      | linter                            | problem                        | location         |
+      | BackgroundDoesMoreThanSetupLinter | Background has non-setup steps | <path_to_file>:3 |
+
+  Scenario: Linting backgrounds with only setup steps
+    Given a linter for backgrounds that do more than setup
+    And the following feature:
+      """
+      Feature:
+
+        Background:
+          Given some setup
+          And some more setup
+          * this is also setup
+      """
+    When it is linted
+    Then no error is reported
+
+  Scenario Outline: Configuration of keywords for different dialect
+    Given a linter for backgrounds that do more than setup has been registered
+    And the following configuration file:
+      """
+      BackgroundDoesMoreThanSetupLinter:
+        Given:
+          - Dado
+        When:
+          - Quando
+        Then:
+          - Então
+          - Entao
+      """
+    And the following feature:
+      """
+      # language:pt
+      Funcionalidade: Feature name
+
+        Contexto: A Background in pt dialect
+          Dado some setup in pt dialect
+          <step>
+      """
+    When the configuration file is loaded
+    And it is linted
+    Then an error is reported:
+      | linter                            | problem                        | location         |
+      | BackgroundDoesMoreThanSetupLinter | Background has non-setup steps | <path_to_file>:4 |
+
+    Examples:
+      | step                                          |
+      | Quando this is an action in pt dialect        |
+      | Então this is a validation in pt dialect      |
+      | Entao this is also a validation in pt dialect |

data/testing/cucumber/features/linters/element_with_common_tags.feature

@@ -1,28 +1,28 @@
-Feature: Element with common tags linter
-
-  As a writer of documentation
-  I want taggable elements to not needlessly have the same tags
-  So that redundancy is minimized
-
-
-  Scenario: Linting
-
-  Note: Also works on outlines that have common tags on their examples
-
-    Given a linter for elements with common tags
-    And the following feature:
-      """
-      Feature:
-
-        @same_tag
-        Scenario:
-          * a step
-
-        @same_tag
-        Scenario:
-          * a step
-      """
-    When it is linted
-    Then an error is reported:
-      | linter                      | problem                                                               | location         |
-      | ElementWithCommonTagsLinter | All tests in Feature have tag '@same_tag'. Move tag to Feature level. | <path_to_file>:1 |
+Feature: Element with common tags linter
+
+  As a writer of documentation
+  I want taggable elements to not needlessly have the same tags
+  So that redundancy is minimized
+
+
+  Scenario: Linting
+
+  Note: Also works on outlines that have common tags on their examples
+
+    Given a linter for elements with common tags
+    And the following feature:
+      """
+      Feature:
+
+        @same_tag
+        Scenario:
+          * a step
+
+        @same_tag
+        Scenario:
+          * a step
+      """
+    When it is linted
+    Then an error is reported:
+      | linter                      | problem                                                               | location         |
+      | ElementWithCommonTagsLinter | All tests in Feature have tag '@same_tag'. Move tag to Feature level. | <path_to_file>:1 |