Gherkinizer Logo

100% free and private. Runs entirely in your browser.

One suite said this 86 different ways.

Every phrasing variation requires its own step definition: code someone had to write, and someone now has to maintain. Select your features folder to see how many redundant steps are cluttering your test suite.

  • a user is logged in
  • the user logs into the system
  • the user logs into their account
  • the user submits the login form with valid credentials
  • the customer is authenticated successfully
  • + 81 more phrasings, by 19 people
the user is logged in

Step-definition explosion, and why it happens to careful teams

Nobody writes a duplicate step on purpose. Someone needs a logged-in user, searches the suite, doesn't find the phrasing they had in mind, and writes it. It passes review, because on its own it is a perfectly good step. Two years and nine people later there are eighty-six ways to say it, and no one decision was wrong.

The cost is not the duplicated text. It is that each phrasing binds to its own implementation, so a change to how logging in works has to be found in eighty-six places, and the ones that get missed fail later, somewhere else, for reasons that don't look related.

We measured this across the feature files written through Gherkinizer: the “logged in” family alone was 168 steps, written 86 different ways, by 19 people who had never met. That is the pattern this tool looks for.

How it works

  1. It reads the steps, not the prose

    Every Gherkin keyword (Given, When, Then, And, But) across your files, ignoring quoted values, <parameters> and numbers. Those are the data a step takes, not the behaviour it describes.

  2. It groups the ones that mean the same thing

    The audit strips away minor variations like articles and tense, so identical intents land in the same cluster. Interchangeable phrasings (logs in, signs in, is authenticated) are treated as one verb. Nothing is sent to a model, so the same suite gives the same report every time.

  3. It counts bindings, not sentences

    Two phrasings that differ only in their data share one step definition, so they are not reported. What gets counted is the number of definitions that would actually disappear if you consolidated.

  4. It tells you which wording to keep

    It highlights the most frequent phrasing to minimise your migration effort, defaulting to the shortest option in a tie.

All four steps happen in your browser. Your feature files are never uploaded. That makes it fast, private, and capable of processing repositories too large to paste into an AI chat window.

Questions

Are my feature files uploaded anywhere?
No. The audit runs entirely in your browser: the files are read locally and analysed on your machine. Nothing is sent to a server, which is also why the tool is free and needs no account.
What counts as a duplicate step?
One behaviour written more than one way, where each phrasing needs its own step definition. Steps that differ only in their data ("the cart contains 3 items" and "the cart contains 0 items") are one binding and are not reported, because reusing a step with different values is the outcome you want.
Does it read my step-definition code as well?
Not yet. It reads .feature files and reports the bindings those steps imply. That is language-agnostic, so it works the same whether your steps are implemented in Java, JavaScript, Python, Ruby or C#.
How sure is it that two steps are the same?
Each cluster receives a confidence rating based on how closely the steps match. "Certain" means the steps are identical once case, spacing and parameters are set aside. "Likely" means the same words in a different arrangement. "Review" means they overlap substantially and you should read them before consolidating, because the tool will not pretend to know your domain.
Why does consolidating step definitions matter?
Every phrasing of a step needs its own binding, and every binding is code that has to be written, understood and kept working. A suite that says "the user is logged in" eighty-six different ways has eighty-six pieces of code doing one job, drifting apart as people change them independently. It is the most common reason teams abandon BDD.