chutney 3.7.0 → 3.8.0

data/usechutney.com/_posts/2024-09-23-welcome-to-jekyll.markdown

@@ -0,0 +1,28 @@
+---
+title:  "Welcome to Jekyll!"
+date:   2024-09-23 20:31:37 +0100
+categories: jekyll update
+---
+You’ll find this post in your `_posts` directory. Go ahead and edit it and re-build the site to see your changes. You can rebuild the site in many different ways, but the most common way is to run `jekyll serve`, which launches a web server and auto-regenerates your site when a file is updated.
+
+Jekyll requires blog post files to be named according to the following format:
+
+`YEAR-MONTH-DAY-title.MARKUP`
+
+Where `YEAR` is a four-digit number, `MONTH` and `DAY` are both two-digit numbers, and `MARKUP` is the file extension representing the format used in the file. After that, include the necessary front matter. Take a look at the source for this post to get an idea about how it works.
+
+Jekyll also offers powerful support for code snippets:
+
+{% highlight ruby %}
+def print_hi(name)
+  puts "Hi, #{name}"
+end
+print_hi('Tom')
+#=> prints 'Hi, Tom' to STDOUT.
+{% endhighlight %}
+
+Check out the [Jekyll docs][jekyll-docs] for more info on how to get the most out of Jekyll. File all bugs/feature requests at [Jekyll’s GitHub repo][jekyll-gh]. If you have questions, you can ask them on [Jekyll Talk][jekyll-talk].
+
+[jekyll-docs]: https://jekyllrb.com/docs/home
+[jekyll-gh]:   https://github.com/jekyll/jekyll
+[jekyll-talk]: https://talk.jekyllrb.com/

data/usechutney.com/docs/configuration/index.md

@@ -0,0 +1,104 @@
+---
+title: "Configuring Chutney"
+layout: single
+permalink: /docs/configuration/
+---
+
+Chutney has a default configuration which may or may not suit your needs. It's rules are defined in a simple YAML configuration file that you can customise.
+
+## Configuration file
+
+You can name your configuration file `chutney.yml` or `.chutney.yml`. The first style is preferred because it is not hidden by default in most file systems.
+
+The file can be placed in the root of your project, or in a subdirectory called `/config`.
+
+Chutney will create a default configuration file for you, `chutney.yml`, in your current directory if you run:
+
+```bash
+chutney --init
+```
+
+It will look something like this, but don't worry, it looks more complicated than it is:
+
+```yaml
+AvoidOutlineForSingleExample:
+    Enabled: true
+AvoidFullStop:
+    Enabled: true
+AvoidScripting:
+    Enabled: true
+AvoidSplatStepsInBackground:
+    Enabled: true
+AvoidSplatStepsInScenarios:
+    Enabled: true
+AvoidTypographersQuotes:
+    Enabled: true
+BackgroundDoesMoreThanSetup:
+    Enabled: true
+BackgroundRequiresMultipleScenarios:
+    Enabled: true
+BadScenarioName:
+    Enabled: true
+EmptyFeatureFile:
+    Enabled: true
+FileNameDiffersFeatureName:
+    Enabled: true
+GivensAfterBackground:
+    Enabled: true
+MissingExampleName:
+    Enabled: true
+MissingExampleTable:
+    Enabled: true
+MissingFeatureDescription:
+    Enabled: true
+MissingFeatureName:
+    Enabled: true
+MissingScenarioName:
+    Enabled: true
+MissingScenarioOutline:
+    Enabled: true
+MissingTestAction:
+    Enabled: true
+MissingVerification:
+    Enabled: true
+InconsistentQuoting:
+    Enabled: true
+InvalidFileName:
+    Enabled: true
+InvalidStepFlow:
+    Enabled: true
+RequiredTagsStartsWith:
+    Enabled: false
+SameTagDifferentCase:
+    Enabled: true
+SameTagForAllScenarios:
+    Enabled: true
+ScenarioNamesMatch:
+    Enabled: false
+TagUsedMultipleTimes:
+    Enabled: true
+TooClumsy:
+    Enabled: true
+TooManyDifferentTags:
+    Enabled: true
+    MaxCount: 3
+TooManySteps:
+    Enabled: true
+    MaxCount: 10
+TooManyTags:
+    Enabled: true
+    MaxCount: 3
+TooLongStep:
+    Enabled: true
+    MaxLength: 80
+UniqueScenarioNames:
+    Enabled: true
+UnknownVariable:
+    Enabled: true
+UnusedVariable:
+    Enabled: true
+UseBackground:
+    Enabled: true
+UseOutline:
+    Enabled: true
+```

data/usechutney.com/docs/disabling-rules/index.md

@@ -0,0 +1,11 @@
+---
+title: "Disabling Rules"
+layout: single
+permalink: /docs/disabling-rules/
+---
+
+With all the best will and good intentions in the world, sometimes you need to break a rule. You might need to do this for a very good reason or because the rule is mis-identifing something that you think is valid.
+
+To do this, use the tag format `@disable<Linter Name>`. For example `@disableTooLongStep`.
+
+If used at the feature level, the linter will be deactivated for the whole file, used at the scenario level, only that one scenario will be excused.

data/usechutney.com/docs/installing/index.md

@@ -0,0 +1,30 @@
+---
+title: "Installing Chutney"
+layout: single
+permalink: /docs/installing/
+---
+
+Chutney is written in Ruby and distributed as a Ruby gem. This means you need to have Ruby installed on your system to use Chutney.
+
+## Installing Ruby
+
+To install Ruby, follow the instructions on the [Ruby website](https://www.ruby-lang.org/en/documentation/installation/).
+
+## Installing Chutney
+
+Once you have Ruby installed, you can install Chutney system-wide by running the following command:
+
+```bash
+gem install chutney
+```
+and update it with:
+
+```bash
+gem update chutney
+```
+or you can install Chutney locally by adding it to your Gemfile (you should do this if you have a Ruby-Cucumber test pack):
+
+```ruby
+gem 'chutney', "~> <latest version number>"
+```
+(you can grab the latest version number from the [RubyGems page](https://rubygems.org/gems/chutney).)

data/usechutney.com/docs/language-server/index.md

@@ -0,0 +1,24 @@
+---
+title: "Chutney Language Server"
+layout: single
+permalink: /docs/language-server/
+---
+
+{: .notice}
+Since v3.8.0
+
+Chutney now includes a Language Server (LSP), which can be used with your favourite editor to provide real-time feedback on your feature files.
+
+The command to start the Language Server is:
+
+```bash
+chutney-lsp
+```
+
+The language server will consume from the standard input and emit to standard output. This means that you can use it with any editor that supports the LSP protocol.
+
+It will listen for open / close and save events to evaluate the current feature file and provide feedback.
+
+## Editor integrations
+
+TBD.

data/usechutney.com/docs/rules/avoid-full-stops/index.md

@@ -0,0 +1,23 @@
+---
+title: "Avoid Full Stops"
+layout: single
+permalink: /docs/rules/avoid-full-stops/
+---
+
+Don't include a full stop (a period) in your steps because it makes reuse a lot harder, espcially if that step suddenly appears in the middle of a scenario.
+
+## Bad
+
+```gherkin
+Given I have visited the website
+When I log in.
+Then I will see my account
+```
+
+## Good
+
+```gherkin
+Given I have visited the website
+When I log in
+Then I will see my account
+```

data/usechutney.com/docs/rules/avoid-outline-for-single-example/index.md

@@ -0,0 +1,28 @@
+---
+title: "Avoid Outline for Single Example"
+layout: single
+permalink: /docs/rules/avoid-outline-for-single-example/
+---
+
+If you have a Scenario Outline, but only one example, then you should convert it to a Scenario because it reduces the complexity of the feature file.
+
+## Bad
+
+```gherkin
+Scenario Outline: Log in with valid credentials
+  Given I have visited the website
+  When I log in with <username> and <password>
+  Then I will see my account
+    Examples: of valid credentials
+      | username | password |
+      | user1    | pass1    |
+```
+
+## Good
+
+```gherkin
+Scenario: Log in with valid credentials
+  Given I have visited the website
+  When I log in with "user1" and "pass1"
+  Then I will see my account
+```

data/usechutney.com/docs/rules/avoid-scripting/index.md

@@ -0,0 +1,33 @@
+---
+title: "Avoid Scripting"
+layout: single
+permalink: /docs/rules/avoid-scripting/
+---
+
+If you find yourself needing to write more than one `when` step, you a probably scripting. This is a bad practice because it makes your tests harder to read and maintain. It also makes it harder to debug when something goes wrong.
+
+It is much better to describe what outcome should happen in your steps and let the automation code handle the implementation details. This makes your tests more readable and easier to maintain.
+
+## Bad
+
+```gherkin
+Scenario: Log in with valid credentials
+  Given I have visited the website
+  When I click the log in button
+  And I enter "user1" in the username field
+  And I enter "pass1" in the password field
+  And I click the submit button
+  Then I will see my account page
+  And I will see my username
+  And I will see my profile picture
+  And I will see my account balance
+```
+
+## Good
+
+```gherkin
+Scenario: Log in with valid credentials
+  Given I have visited the website
+  When I log in with "user1" and "pass1"
+  Then I will see my account
+```

data/usechutney.com/docs/rules/avoid-splat-steps-in-background/index.md

@@ -0,0 +1,25 @@
+---
+title: "Avoid Splat Steps in Background"
+layout: single
+permalink: /docs/rules/avoid-splat-steps-in-background/
+---
+
+Splat steps (using an asterisk `*`) can obscure the what kind of step is present and make it less like reading natural language.
+
+## Bad
+
+```gherkin
+Background:
+  Given I have visited the website
+  * I have logged in
+  * I have viewed sale items
+```
+
+## Good
+
+```gherkin
+Background:
+  Given I have visited the website
+  And I have logged in
+  And I have viewed sale items
+```

data/usechutney.com/docs/rules/avoid-splat-steps-in-scenarios/index.md

@@ -0,0 +1,29 @@
+---
+title: "Avoid Splat Steps in Scenarios"
+layout: single
+permalink: /docs/rules/avoid-splat-steps-in-scenarios/
+---
+
+Splat steps (using an asterisk `*`) can obscure the what kind of step is present and make it less like reading natural language.
+
+## Bad
+
+```gherkin
+Scenario: Log in with valid credentials
+  Given I have visited the website
+  * I have logged in
+  * I have viewed sale items
+  When I view special offers
+  Then I will see my discount code
+```
+
+## Good
+
+```gherkin
+Scenario: Log in with valid credentials
+  Given I have visited the website
+  And I have logged in
+  And I have viewed sale items
+  When I view special offers
+  Then I will see my discount code
+```

data/usechutney.com/docs/rules/avoid-typographers-quotes/index.md

@@ -0,0 +1,24 @@
+---
+title: "Avoid Typographers' Quotes"
+layout: single
+permalink: /docs/rules/avoid-typographers-quotes/
+---
+
+Cutting and pasting from Word documents? Is that pasting in curly-quotes instead of neutral ones you would type on a keyboard? Are you sure that’s what you want?
+
+Typographers' quotes are hard to differentiate from neutral ones in text editors but they are not the same characters and this can make it very hard to maintain feature files and their backing steps. Take a look at the 'bad' example: it's not at all obvious at first sight.
+
+## Bad
+
+```gherkin
+Scenario: Log in with valid credentials
+  When I visit the website
+  Then I will see the message “account information”
+```
+
+## Good
+```gherkin
+Scenario: Log in with valid credentials
+  When I visit the website
+  Then I will see the message "account information"
+```

data/usechutney.com/docs/rules/background-does-more-than-setup/index.md

@@ -0,0 +1,28 @@
+---
+title: "Background Does More Than Setup"
+layout: single
+permalink: /docs/rules/background-does-more-than-setup/
+---
+
+The `Background` should only perform common setup activities to prepare the scenarios that follow. They should not contain any `When` or `Then` steps, only `Given`.
+
+## Bad
+
+```gherkin
+Background:
+  Given I have visited the website
+  When I log in
+
+Scenario: logging in
+  Then I will see my account
+```
+
+## Good
+```gherkin
+Background:
+  Given I have visited the website
+
+Scenario: logging in
+  When I log in
+  Then I will see my account
+```

data/usechutney.com/docs/rules/background-requires-multiple-scenarios/index.md

@@ -0,0 +1,26 @@
+---
+title: "Background Requires Multiple Scenarios"
+layout: single
+permalink: /docs/rules/background-requires-multiple-scenarios/
+---
+
+If you only have one scenario, you don't need a `Background`. The `Background` should only be used when you have multiple scenarios that share the same setup steps.
+
+## Bad
+
+```gherkin
+Background:
+  Given I have visited the website
+
+Scenario: logging in
+  When I log in
+  Then I will see my account
+```
+
+## Good
+```gherkin
+Scenario: logging in
+  Given I have visited the website
+  When I log in
+  Then I will see my account
+```

data/usechutney.com/docs/rules/bad-scenario-name/index.md

@@ -0,0 +1,28 @@
+---
+title: "Bad Scenario Name"
+layout: single
+permalink: /docs/rules/bad-scenario-name/
+---
+
+{: .notice}
+English language only.
+
+The name of a scenario should avoid words like 'test' and 'check'. The name should be a description of the scenario, not a statement of what it does.
+
+## Bad
+
+```gherkin
+
+Scenario: checking the login
+  Given I have visited the website
+  When I log in
+  Then I will see my account
+```
+
+## Good
+```gherkin
+Scenario: logging in
+  Given I have visited the website
+  When I log in
+  Then I will see my account
+```

data/usechutney.com/docs/rules/empty-feature-file/index.md

@@ -0,0 +1,7 @@
+---
+title: "Empty Feature File"
+layout: single
+permalink: /docs/rules/empty-feature-file/
+---
+
+You have a feature file with no content. This is not a valid feature file. A feature file should contain at least one scenario.

data/usechutney.com/docs/rules/file-name-differs-feature-name/index.md

@@ -0,0 +1,37 @@
+---
+title: "File Name Differs From Feature Name"
+layout: single
+permalink: /docs/rules/file-name-differs-feature-name/
+---
+
+The name of a feature file should match the name of the feature it describes. This makes it easier to find the feature file that contains a specific scenario.
+
+Case and punctuation can vary between the feature name and the file name, but the words should match.
+
+## Bad
+
+{: .notice}
+`user.feature`
+
+```gherkin
+Feature: logging in
+
+  Scenario: logging in
+    Given I have visited the website
+    When I log in
+    Then I will see my account
+```
+
+## Good
+
+{: .notice}
+`logging-in.feature`
+
+```gherkin
+Feature: logging in
+
+  Scenario: logging in
+    Given I have visited the website
+    When I log in
+    Then I will see my account
+```

data/usechutney.com/docs/rules/givens-after-background/index.md

@@ -0,0 +1,36 @@
+---
+title: "Givens After Background"
+layout: single
+permalink: /docs/rules/givens-after-background/
+---
+
+If you have a `Background` section in a feaure file and your scenarios still need to do some setup, you should start immediately with an `And` step. This makes it clear that the setup is in addition to the background and makes it obvious that the scenario is not sufficient on its own.
+
+This is important when reading a scenario as it reminds the reader that the scenario is not self-contained.
+
+## Bad
+
+```gherkin
+Feature: logging in
+
+  Background:
+    Given I have visited the website
+
+  Scenario: logging in
+    Given I have logged in
+    When I view my profile
+    Then I will see my account
+```
+
+## Good
+
+```gherkin
+
+Background:
+    Given I have visited the website
+
+  Scenario: logging in
+    And I have logged in
+    When I view my profile
+    Then I will see my account
+```

data/usechutney.com/docs/rules/inconsistent-quoting/index.md

@@ -0,0 +1,29 @@
+---
+title: "Inconsistent Quoting"
+layout: single
+permalink: /docs/rules/inconsistent-quoting/
+---
+
+Use either single or double quotes consistently throughout your feature files. This makes it clear to the reader where your strings and variables are.
+
+## Bad
+
+```gherkin
+Feature: logging in
+
+  Scenario: logging in
+    Given I have visited the website
+    When I log in with "username" and 'password'
+    Then I will see my account
+```
+
+## Good
+
+```gherkin
+Feature: logging in
+
+  Scenario: logging in
+    Given I have visited the website
+    When I log in with "username" and "password"
+    Then I will see my account
+```

data/usechutney.com/docs/rules/invalid-step-flow/index.md

@@ -0,0 +1,31 @@
+---
+title: "Invalid Step Flow"
+layout: single
+permalink: /docs/rules/invalid-step-flow/
+---
+
+Scenarios should follow the Given-When-Then structure. This makes it clear to the reader what the scenario is doing and what the expected outcome is.
+
+You should not have `Then` steps before `When` steps, or `When` steps before `Given` steps, and you should not have `Given` steps after `When` steps.
+
+## Bad
+
+```gherkin
+Feature: logging in
+
+  Scenario: logging in
+    Given I have visited the website
+    Then I log in with "username" and 'password'
+    When I will see my account
+```
+
+## Good
+
+```gherkin
+Feature: logging in
+
+  Scenario: logging in
+    Given I have visited the website
+    When I log in with "username" and "password"
+    Then I will see my account
+```

data/usechutney.com/docs/rules/invalid_file_name/index.md

@@ -0,0 +1,19 @@
+---
+title: "Invalid File Name"
+layout: single
+permalink: /docs/rules/invalid-file-name/
+---
+
+The name of the feature file should be in `snake_case` and end with `.feature`. It should not be in `mixedCase` or contain spaces. This makes sure that the feature file can easily be found on different types of operating system which have different file naming conventions.
+
+## Bad
+
+{: .notice}
+`Logging In.feature`
+<br/>
+`logginIn.feature`
+
+## Good
+
+{: .notice}
+`logging_in.feature`

data/usechutney.com/docs/rules/missing-example-name/index.md

@@ -0,0 +1,49 @@
+---
+title: "Missing Example Name"
+layout: single
+permalink: /docs/rules/missing-example-name/
+---
+
+If you have more than one example table in a scenario, you should give each example a name. This makes it easier to understand what each example is testing.
+
+## Bad
+
+```gherkin
+Feature: logging in
+
+  Scenario: logging in
+    Given I have visited the website
+    When I log in with "username" and "password"
+    Then I will see my account
+
+    Examples:
+      | username | password |
+      | user1    | pass1    |
+      | user2    | pass2    |
+
+    Examples:
+      | username | password |
+      | admin1   | pass1    |
+      | admin2   | pass2    |
+```
+
+## Bad
+
+```gherkin
+Feature: logging in
+
+  Scenario: logging in
+    Given I have visited the website
+    When I log in with "username" and "password"
+    Then I will see my account
+
+    Examples: of regular users
+      | username | password |
+      | user1    | pass1    |
+      | user2    | pass2    |
+
+    Examples: of admin users
+      | username | password |
+      | admin1   | pass1    |
+      | admin2   | pass2    |
+```