UnifiedBDDLinter: A Tool to Detect and Remediate Quality Anti-Patterns in Gherkin Feature Files

This dataset captures the results of quality-linting 20,034 Behavior-Driven Development (BDD) Gherkin .feature files mined from 38 public GitHub repositories, measured before and after an automated, form-preserving repair. Every file was independently evaluated by three linters namelygherkin-lint, cuke_linter, and a native 28-rule BDD linter, so the data supports paired before/after analysis of linting violations and of automated-repair effectiveness on BDD specifications. Background Gherkin .feature files are living documentation: a Feature decomposes into Scenarios of Given–When–Then steps that serve simultaneously as human-readable requirements and machine-executable acceptance tests. Their quality is policed by a fragmented, partly contradictory set of linters. This dataset quantifies, at scale and on real-world code, how many violations these linters report and how many an automated fixer can resolve. How the data was produced For every .feature file the following pipeline was executed: Lint (before): Run all three linters on the original file; record each tool's raw output and violation count. Fix: Apply a form-preserving auto-fixer to a copy of the file (the original is never modified). The fixer performs only mechanical, meaning-preserving edits such as indentation, trailing whitespace, blank-line collapsing, end-of-file newline, filename casing, and structural naming and deliberately leaves semantic issues untouched. Lint (after): Re-run all three linters on the fixed copy; record output and counts. Record: Write one CSV row with the 16 fields below. The three linters gherkin-lint (Node.js) : Syntactic style: indentation, tags, blank lines, kebab-case filenames. cuke_linter (Ruby) : Structural smells: overly long steps, missing verification steps, too-many-steps scenarios, snake_case filenames. Native BDD linter : 28 rules across four families (Style, Structure, Workflow, and Business-Readability Quality). The three tools use different rule sets and counting granularities, so their counts are recorded separately and are not summed instead they are independent measurements of the same files. File and schema A single UTF-8 CSV file, one row per file (20,034 rows), 16 columns: Column Type Description Repository_Name text Source GitHub repository File_Path text Path of the .feature file Gherkin_Lint_Errors_Before text gherkin-lint raw output, before fixing Gherkin_Lint_Errors_Before_nums int gherkin-lint violation count, before Cuke_Lint_Errors_Before text cuke_linter raw output, before Cuke_Lint_Errors_Before_nums int cuke_linter violation count, before BDD_Lint_Errors_Before text native linter raw output, before BDD_Lint_Errors_Before_nums int native violation count, before Gherkin_Lint_Errors_After text gherkin-lint raw output, after fixing Gherkin_Lint_Errors_After_nums int gherkin-lint violation count, after Cuke_Lint_Errors_After text cuke_linter raw output, after Cuke_Lint_Errors_After_nums int cuke_linter violation count, after BDD_Lint_Errors_After text native linter raw output, after BDD_Lint_Errors_After_nums int native violation count, after Gherkin_Issues_Fixed int gherkin-lint before − after Cuke_Issues_Fixed int cuke_linter before − after Format notes: Text columns hold raw, newline-separated linter output (empty when a file has no violations). *_nums Columns are integer counts; a value of -1 denotes a linter error or timeout on that file. *_Issues_Fixed = *_Before_nums − *_After_nums. Summary statistics (all 20,034 files) gherkin-lint: 1,163,482 → 167,902 violations (−85.6%) Native linter: 1,532,486 → 309,024 violations (−79.8%) cuke_linter: 302,053 → 297,461 violations (−1.5% — mostly semantic rules the fixer does not target) Files improved: 99.8%; regressions: 0 Per-repository gherkin-lint reduction: median 90.7%, minimum 32%, none negative Of the mechanically fixable (form) violations, 99.9% were resolved (1,222,805 of 1,224,408); the remaining ~308,000 are semantic violations left unchanged by design. Possible uses Study the effectiveness and safety of automated repair on BDD/Gherkin specifications. Analyze agreement and disagreement between independent linters on the same files (e.g., the kebab-case vs. snake_case filename conflict). Characterize the prevalence and distribution of BDD quality issues across real-world projects. Benchmark or train tools for specification-quality assessment and repair. Provenance and verification The dataset is self-checking: summing the *_nums columns reproduces the aggregate statistics above — e.g., Gherkin_Lint_Errors_Before_nums sums to 1,163,482 and Gherkin_Lint_Errors_After_nums to 167,902 across the 20,034 rows.