Paste test names, one per line, into the Test Naming Linter and choose your team's naming pattern. It flags names that miss that pattern. The score measures spelling and shape, not whether a test explains its behavior.
\n\nA CI failure shows checkout works. You still have to open the test to learn whether an empty cart, a declined card, or a completed order failed. A more specific name can carry that context into the failure list. This tool helps clean up a batch of names before a rename reaches the repository.
Open the tool, select Method_State_Behavior, clear the sample names, and paste these lines:
Checkout_EmptyCart_ShowsError\ncheckout works\nCheckout_DeclinedCard_ShowsRetryThe linter reports two passed, one failed, and a score of 67 out of 100. It rejects checkout works because this mode requires three underscore-separated segments that begin with capital letters. The tool gives the expected shape beside the rejected line.
The useful result is the failed name, not the score. A clearer replacement might be Checkout_EmptyCart_ShowsError, but only if that is what the test actually checks. Read its assertion before renaming it.
The menu offers Method_State_Behavior, Given_When_Then, and shouldBehaviorWhenState. Changing the menu loads a new sample, so paste your own names after selecting the pattern. The first mode checks three PascalCase-like segments. The second checks that separate Given, When, and Then tokens appear in order. The third checks a should prefix and a later When.
These are the tool's rules, not universal requirements for test code. Pick one house style that helps your team read failures. If your suite deliberately uses descriptive sentences, a red result here is a style mismatch, not a broken test.
\n\nThere is a sharp edge in Given_When_Then mode: the implementation looks for those three tokens in order but does not verify that the words between them describe a real setup, action, and outcome. Given_When_Then passes the shape check while saying almost nothing. A name can also pass while the assertion checks something else entirely.
Use the linter to find inconsistent names quickly. Review behavior against assertions in code. The browser tool does not change test files or enforce a rule in CI; put the agreed rule in your repository if you need continuous enforcement.
\n\nDoes a 100 score mean the names are good? No. It means every non-empty line matched the selected syntax rule. The linter cannot judge whether the test name matches the test body.
\n\nCan I mix styles in one check? One pattern is active at a time. Split the input by convention or decide which style the suite should use.
\n\nPaste names from one failing test file. Keep the rejected lines, inspect their assertions, and rename only the tests whose current names hide the failed behavior. Save one before/after failure name in the review so the change has a reason beyond a higher score.
\n\n