Break your own code before the release does

I rewrote eleven declared props in akira-io/ui so that each one ignored the value it was handed and fell back to its default. Then I ran the suite. Every test passed.

Eleven props. Zero failures. The props were documented, exported, and shipped to anyone installing the package. Two of them, id and name, are the documented way to put two login forms on one page. Nothing exercised them with a value that was not the default.

A test you have never watched fail is not a test. It is a line in a report.

The test that tested nothing

This one shipped in v2.2.0:

// src/blocks/login-form/index.test.ts
it('re-exports LoginFormStatusProps alongside the other part prop types', () => {
    const props: LoginFormStatusProps = { message: 'ok' };

    expect(props.message).toBe('ok');
});

Vitest transpiles TypeScript. It does not typecheck it. The annotation is stripped before the test ever runs, so what executes is an object with a message key being asked whether it has a message key. Delete the re-export the test exists to guard and it stays green.

It fails under tsc --noEmit. Nothing ran tsc --noEmit.

The argument nobody read

The one that would have cost other people money:

// scripts/release-dist-tag.mjs
export function resolveDistTag(version, currentLatest = '') {
    const match = VERSION_PATTERN.exec(version);
    if (!match) {
        throw new Error(`${version} is not a valid semantic version`);
    }

    return match[4] ?? 'latest';
}

currentLatest is a parameter. The release workflow queries the registry for it and passes it in. The function never reads it. Every stable version is tagged latest, unconditionally.

Here is what that buys. The package sits at 2.1.0. A security fix lands on the v1 line and ships as v1.3.2, which is an ordinary thing to do. The publish tags it latest. From that moment every npm install, every Dockerfile pinning @latest, every CI job resolving the floating tag, gets a v1 release. Teams on v2 reinstall and receive a package missing a whole surface, with a different peer range.

The workflow goes green. The release page looks correct. The only symptom is other people’s builds failing against an API from two majors ago, and they find it before you do.

That is the shape of the expensive bug. It does not throw.

The obvious objection

Mutation testing is a solved category. Stryker does this at scale, generates the mutants, scores the suite, and does not need me to hand-pick eleven props.

True, and I will reach for it. But a tool was not the thing missing. I knew the props were declared. I could read the file. What I had been doing was accepting a green run as evidence that they worked, and no tool installs that doubt for you. The tool scales the method once you already refuse to trust the report.

The cheap version costs one afternoon: pick the thing a test claims to guard, break it, run the test. If it passes, you have found a hole. If it fails, you have found a test. Either result is worth more than the run you did not question.

What it changed

The suite that survived eleven mutations now fails against all of them, and the props that mattered are asserted with values that are not the default. resolveDistTag reads the argument it accepts, so a lower-major backport gets its own line tag instead of the default one. A workflow runs the tests, the typecheck, and the format check on every pull request, which is what makes the type-only assertion mean something at all.

None of that is clever. All of it existed because I stopped reading green as proof.

Green is a claim. Make it prove itself.