Cucumber support

Detection#

Cucumber projects are detected through .feature files, Cucumber configuration files, package dependencies, and conventional feature locations.

This works for behaviour-driven suites in JavaScript, Java, and mixed repositories because the feature files are the primary source of test intent. If feature files are stored outside conventional folders, set a framework directory override so generated examples and archived specifications do not pollute the active history.

Parsed information#

Test Chronicle records scenario names, feature files, line numbers, feature groupings, and tags. Scenario outline example rows are expanded into individual recorded cases.

Tags provide useful review context for smoke, regression, feature, or domain labels. Feature names and scenario locations also make it easier to trace a dashboard change back to the behaviour being described rather than only the step implementation code.

Limits and configuration#

Cucumber step definitions are not treated as separate tests. Test Chronicle follows scenarios and outlines because those are the source-level behaviours that teams review and maintain. Generated feature files should be excluded unless they are intentionally owned as part of the suite.

Use project areas when feature folders map to product domains. Area filters help security, QA, and engineering reviewers ask whether behaviour coverage changed in the part of the product they care about.

Historical changes#

Scenario additions, deletions, renames, and maintenance changes are mapped to commits using the same history process as code-based frameworks.

Use a Cucumber directory override or directory exclusion in the Test Chronicle project settings when feature files live outside conventional locations or generated files should be ignored.

This turns Cucumber history into more than a feature-file count. Reviewers can see whether scenarios were clarified, renamed, removed, or added alongside product changes, with commit and contributor context retained.