Add Gherkin Linting to Megalinter Workflow and Update Implementation …

[ravindrapalaskar17]

What type of PR is this? Close the issue: - https://github.com/camaraproject/Commonalities/issues/142

Add one of the following kinds:

enhancement/feature Documentation\

What this PR does / why we need it: This PR includes the addition of Gherkin linting in the Megalinter workflow to lint the test contribution feature files, along with implementation guideline documentation

Which issue(s) this PR fixes: Fixes #142

Open Points for Discussion: Standard Name Length: The standard name length for features, steps, and scenarios was initially set to 70 characters. However, after testing all feature files, we have adjusted it to 90 for features, 190 for steps, and 190 for scenarios.

List of No-Restricted-Tags: Review and finalize the list of tags that should be restricted or allowed.

Max-Scenarios-Per-File: The standard is 15 scenarios per file, but we have increased this limit to 50 scenarios per file.

Keyword Logical Order: Discuss the logical order of keywords (Given, When, Then, And) and ensure it is consistently enforced.

New Line at EOF: Decide whether the rule for enforcing a new line at the end of files should be turned on or off.

No-Restricted-Patterns: Identify and agree on a list of words or patterns that should be avoided in the Feature, Background, and Scenario sections.

File Name Format: Decide on a standard file naming convention: PascalCase, Title Case, camelCase, kebab-case, or snake_case.

Indentation: Finalize the indentation standards for Gherkin files (e.g., number of spaces or tabs to use).

[linux-foundation-easycla[bot]]

The committers listed above are authorized under a signed CLA.

• :white_check_mark: login: ravindrapalaskar17 (7d06c506074cefc99c2ccfa388ab2ad4402244d0)

[Kevsy]

Nice work @ravindrapalaskar17 !

For the Open Points for Discussion:

• should each Feature require a description? (I'm not sure if that's covered by 'poor description' from the gherkin-lint docs)

[hdamker]

Thanks @ravindrapalaskar17!

Regarding:

File Name Format: Decide on a standard file naming convention: PascalCase, Title Case, camelCase, kebab-case, or snake_case.

Within QualityOnDemand we have currently a mix of kebab-case and camelCase (following the formats of the components of the filename): <api-name>-<operationId>.feature

cc: @jlurien

[rartych]

Regarding:

File Name Format: Decide on a standard file naming convention: PascalCase, Title Case, camelCase, kebab-case, or snake_case.

Within QualityOnDemand we have currently a mix of kebab-case and camelCase (following the formats of the components of the filename): <api-name>-<operationId>.feature

This format is allowed in API Testing Guidelines As filename convention (not only casing) can be easily verified I propose to switch this rule off.

[ravindrapalaskar17]

Nice work @ravindrapalaskar17 !

For the Open Points for Discussion:

• should each Feature require a description? (I'm not sure if that's covered by 'poor description' from the gherkin-lint docs)

This part is a configuration for the no-restricted-patterns rule, which is applied to various sections of Gherkin feature files. It helps restrict the use of certain terms or patterns in the description, feature, and background sections. for E.g. Initial Sample Terms: These are just examples of restricted terms (poor description, validate, verify, etc.), which can be customized or updated as per suggestions from CAMARA.

[PedroDiez]

Regarding Indentation:

Indentation:
Finalize the indentation standards for Gherkin files (e.g., number of spaces or tabs to use).

Propose to change: Based on how currently Test inputs are provided

• Background: 2
• example: 6

Other comments: Also agree with this comment

Rest of current configuration proposal seems to work fine:

• Tested here in Carrier Billing WG