# 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.

- Author: [Shashank Rawlani](https://shashank.rawlani.com)

- Published: 2026-09-30T05:30:00.000Z

- Updated: 2026-10-14T10:26:49.431Z

- Category: Tools & Reviews

- Canonical source: https://automationtester.in/blog/tools-reviews/audit-test-names-before-ci

- Tags: test-naming, ci-debugging, test-maintenance, developer-tools

Paste test names, one per line, into the [Test Naming Linter](https://automationtester.in/tools/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_ShowsRetry
```

The 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](https://automationtester.in/tools/test-naming-linter): the available patterns, input method, results, and scoring interface.

## Continue reading on AutomationTester.in

- [Create a Failure Triage Toolkit Before the Next Flake](https://automationtester.in/blog/tools-reviews/failure-triage-toolkit-before-flake)
- [Test Cron Schedules by Their Fire Times, Not Their Strings](https://automationtester.in/blog/tools-reviews/verify-cron-schedules-time-zones-boundaries)
- [Build a k6 Load Model from Real Traffic, Not a VU Count](https://automationtester.in/blog/tools-reviews/generate-k6-load-model-traffic-assumptions)
- [Freeze Generated Test Data Before CI Needs It](https://automationtester.in/blog/tools-reviews/freeze-generated-test-data-fixtures)
- [Review Required Fields in a Generated JSON Schema](https://automationtester.in/blog/tools-reviews/review-generated-json-schema-required-fields)

Source: [Audit Test Names Before They Reach CI](https://automationtester.in/blog/tools-reviews/audit-test-names-before-ci) by Shashank Rawlani.