Audit Test Names Before They Reach CI
A CI failure named 'checkout works' hides the failing behavior. Check a batch of names against one convention, then compare each rename with the assertion it describes.
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.
A 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.
Try three checkout names
Open the tool, select Method_State_Behavior, clear the sample names, and paste these lines:
Checkout_EmptyCart_ShowsError
checkout works
Checkout_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.
Choose the pattern your suite uses
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.
A green name can still mislead
There 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.
Questions that come up
Does 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.
Can 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.
Take a failing file into review
Paste 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.
The naming tool
- AutomationTester.in Test Naming Linter: the available patterns, input method, results, and scoring interface.