Gherkin at Scale: Need for Static Analysis / Language Server Support

[kiarash8112]

Gherkin at Scale: Need for Static Analysis / Language Server Support

Context

I work at an ERP company with 100,000+ customers. We heavily use Gherkin for BDD, and currently maintain 150,000+ lines of .feature files.

We rely on structured conventions where we track entities using keys:

Given user inserts new company having following data
    | Key       | IsHolding |
    | $company1 | false     |

And user inserts new storagetype having following data
    | Key           | Company   |
    | $storagetype1 | $company1 |

And user inserts new store having following data
    | Key     | StorageTypeRef | PlantRef | Company   |
    | $store1 | $storagetype1  | $plant1  | $company1 |

---

Problem

At scale, Gherkin becomes hard to maintain due to lack of tooling:

• No real autocomplete or linting
• No go-to-definition / reference navigation
• Copy-paste of step definitions across files

---

Idea: Static Analysis / Gherkin Language Server

A tool that could:

1. Dependency-aware autocomplete

Detect that a step like:

user inserts new store having following data

depends on:

• $company1
• $storagetype1
• $plant1

and automatically suggest or insert missing setup steps.

---

2. Go to definition (F12 support)

Navigate directly to:

• step definitions
• key definitions across feature files

---

3. Background optimization

Detect unused setup data in Background sections and minimize execution scope.

---

Example issue

Large backgrounds often include unnecessary data:

Given user inserts new company having following data
    | Key       | IsHolding |
    | $company1 | false     |
    | $company2 | false     |
    | $company3 | false     |

but a scenario may only require $company1.

A dependency-aware tool could reduce this automatically.

---

Questions

1. How common is structured, key-based Gherkin usage in large teams?

2. How do teams handle static analysis limitations for generic steps like:

   Given a logged in user
   And the database is seeded
   

---

Why this matters

At our scale (150k+ lines), better tooling could significantly improve:

• Developer speed
• Scenario maintainability
• CI pipeline performance

[luke-hill]

GitHub Copilot and other tools are available to detect unused step definitions.

But as for the generic maintenance of files, this wouldn't be the purvey of cucumber it would be the responsibility elsewhere

[vitalets]

Maybe you can create a custom rule for gherkin-lint and run the linter over these files.

[laeubi]

At scale, Gherkin becomes hard to maintain due to lack of tooling:

All this is offered by https://github.com/cucumber/cucumber-eclipse

Gherkin Language Server

I already made a prototype of this but there is also https://github.com/cucumber/language-server

So many things are possible, but usually blocked by the fact that there are many demands but little support for those "ERP company with 100,000+ customers". So if it is really important to your business, you should start funding cucumber here https://opencollective.com/cucumber and helping improving it (it is all open source)! Of course you can also hire someone (e.g. me) to do the work for you