The green check has a definition

The badge can stay while its meaning changes

The green badge can be telling the truth after its meaning has changed. A pull-request job still called test may still invoke npm test, yet the package script underneath can stop selecting an integration file. Every selected assertion passes. The familiar badge now supports a smaller claim about the application, and a reviewer looking only for red has a good chance of missing the difference.

Verification configuration is executable behaviour. A workflow chooses a command, that command chooses files, and those files make assertions about particular paths through the application. A change at any link can alter the evidence without changing the top-level job name. This does not make every test edit suspicious. Tests become obsolete, duplicated or inappropriate. It does mean that retiring a check is a change to what the team can claim about the next green result.

The example uses an invented export mapper that substitutes unassigned for a blank reference. Its proposed contract instead requires rejection. An integration check challenges that behaviour, while a unit check exercises an unrelated label formatter. The downloadable resource creates both in a temporary directory and runs their selections locally, installing no packages. There is no real contributor or hosted CI run to judge here. That makes it possible to examine the change in evidence without guessing at anyone’s motives for changing a test command.

Follow the command until it reaches an assertion

The illustrative workflow has a test job whose final step invokes npm test. In the first package configuration, that script calls Node's test runner with two explicit paths: unit/labels.test.mjs and integration/export.test.mjs. Explicit paths make this small demonstration independent of shell glob expansion. Node's current documentation describes command-line file selection and its test runner; GitHub documents the workflow job and run-step structure.[1][2] The local experiment uses those ordinary mechanisms without claiming that current documentation is a snapshot of October 2024.

The label formatter trims spaces, and its unit assertion passes. The export assertion supplies an empty reference and expects an exception before export; it fails because the mapper returns the substitute value. Both files are tests, but that shared name does not make their evidence interchangeable. A correct label tells us nothing about the export’s blank-reference rule. Following the assertion back to the behaviour it challenges is what makes the distinction visible.

Change only the package script so npm test selects the unit path. The mapper is untouched, the formatter passes and the process exits successfully. The resource ran both selections with Node v22.23.1: exit one for the wider selection and zero for the narrowed one. It also invoked the integration file directly and confirmed the missing-expected-exception assertion failure. That last check matters because it tells us the export requirement failed, rather than merely finding an import error or a test process that never launched.

A successful run describes the selected assertions. In this example, removing the only selected assertion about export references turns the result green while leaving the mapper unchanged. Including selected file identities in the test summary would help the reviewer notice that change. The badge remains an accurate report of the run, but the command and fixtures are needed to understand which behaviour the result can support.

The verification diff deserves its own explanation

Why did the export file stop belonging to this command? The answer may be entirely sound: its route was removed, the rejection rule changed, or another job now checks the same behaviour. Show that replacement evidence or make the withdrawn promise explicit. Here the mapper and contract remain as they were, so removing the file leaves a specific question unanswered. The review need not regard test maintenance as suspicious to ask where that question will now be checked.

A performance argument can also be legitimate. Running every end-to-end test on every documentation edit may waste time. The remedy is a declared selection policy whose boundary can be inspected, not an assumption that unit tests cover everything faster. If path-based selection is introduced, exercise changes that affect shared mappings or configuration indirectly. A file under a different directory can alter the behaviour being protected. The test command's selection semantics deserve the same care as the code's data-selection semantics.

Trace the export promise in both directions. Starting at the badge, follow the job and resolved command to integration/export.test.mjs: is the blank-reference check selected? Starting at the mapper, find the assertion that supplies an empty reference and expects rejection: does the selected check actually reach that behaviour? A file can be omitted, or included while no longer exercising the relevant branch. The label formatter passes in either case. A focused review can therefore explain a missing link without requiring the reviewer to memorise every test in the repository. It also gives a replacement check a concrete requirement to demonstrate, rather than accepting a similar filename as equivalent coverage.

Selection can also change through a skipped test, empty fixture, job condition or wrapper that discards a failing exit code. Each mechanism needs its own inspection; the worked example tests only package-script selection. They can all alter what the displayed result establishes. Reviewing those changes as executable configuration helps the team account for evidence that disappeared, including when the affected files are outside the application's shipped code.

Keep legitimate maintenance possible

An inflexible rule that tests may never be removed would create its own problems. A duplicate suite can slow feedback without adding confidence; an assertion tied to an obsolete interface can obstruct a sound migration. The review should preserve the purpose of the check, not its exact filename forever. If the requirement has moved, demonstrate where it is now challenged. If the requirement has ended, make that product decision visible. Both are stronger explanations than saying the file was inconvenient to keep passing.

Likewise, deliberately failing an old fixture is not always evidence against a correct change. The expected result may no longer be valid. In the blank-reference example, the rejection rule is stated as the proposed contract so the failure has a clear meaning. A real review must establish that meaning with the people responsible for the export. Otherwise an engineer can be asked to preserve a historical assertion after everyone has forgotten whether the downstream consumer still needs it.

An independent check can be worthwhile when the same change alters behaviour and the route used to approve it. Here the direct integration invocation confirms the intended failure outside the edited package script. In a real repository, a separately controlled suite or a reviewed sample with a recorded expectation might serve that purpose. Neither is free to maintain, and an ordinary refactor may not need a second verification system. Independence earns its cost where the edited command would otherwise get to define its own success.

Make the next green result explainable

A compact review note can name the job, resolved command, selected fixtures and the requirement each added or removed fixture covers. It can also state what was not run. This is not a demand for a long report on every pull request. It is a way to make a meaningful selection change reviewable while the relevant context is still present. After the merge, a future maintainer should not have to infer whether an integration test vanished accidentally or because its contract was retired.

After the narrower command passes, we know that label formatting passed; we have stopped asking it about blank export references. The mapper has not improved. A reviewer can still accept the selection change, but needs to decide whether the missing coverage has a replacement or whether the promise itself is being retired. Keeping that explanation with the change leaves the next maintainer something better than the old job name from which to infer what a green result means.