2500 tests in my public repository and nothing was running them

Someone asked me a simple question about my own project: what are all those tests actually for. The honest answer turned out to be that they were not for anything, because nothing was running them.

Three findings, each verified separately.

There was no CI. No .github/workflows/ in the tree and none in its history. Every test in that repository ran only when a person typed cargo test by hand, which meant they ran when I felt like it and never on a pull request.

One crate was not in the workspace at all. crates/gx-adapter-time was neither in the members list nor in exclude, and cargo answers that state with:

current package believes it's in a workspace when it's not

There is no build path to that directory. It shipped in the published repository, so every person who cloned the project received a directory that cannot compile.

The bundled end-to-end script could not pass in the bundled tree. tools/e2e.sh carried a floor of MIN_PROBES=2822 and the tree it shipped with had roughly 2500. The script exits 16 on a floor violation. It shipped exiting 16.

Counted today on the frozen tree:

$ grep -rn '#\[test\]' --include=*.rs . | wc -l
2485
$ grep -rn '#\[tokio::test' --include=*.rs . | wc -l
89
$ find . -name '*.rs' | wc -l
592

The one that stung

Adding the missing crate to the workspace made ten tests run for the first time. All ten passed. One of them is named:

$ grep -rn 'the_undo_window_closes_because_firedness_is_inside_the_fingerprint' --include=*.rs .
./crates/gx-adapter-time/tests/wm4a_time_substrate.rs:170

That is the invariant the product is sold on. It is the sentence in the README rendered as an assertion. It had never executed.

The pattern is not random. The core claim gets the most careful test and the least exercise, because the careful test lives in the newest crate, and the newest crate is the one nobody remembered to wire into the build.

The root that was already written down

The public workspace root explains an adjacent failure in its own header, and I had read it without connecting the two:

Before this split the public Cargo.toml was the private one verbatim, so it declared 19 members while a public clone carried 14, and cargo refuses to load a workspace whose member manifest is missing. Measured on an anonymous fresh clone before this fix: cargo metadata exit 101, cargo build --workspace exit 101.

Every cargo command in the published repository failed before it read a line of Rust. The tests were not failing. They were unreachable, which produces no output at all, and no output is the state a repository sits in comfortably for months.

There is a smaller trap recorded in the same file. A hand-written parser that reads the members array to cross-check the crate count treats every line between the brackets as a member, so a two-line comment placed among the paths was counted as two crates and a test reported 20 against 18, naming a fragment of prose as a crate name.

What I got wrong

I have argued in public that code is the proof and that a test suite is internal hygiene. I still think the second half of that is right. What I had not noticed is that I was using the size of the suite as evidence anyway, in my own head, as a reason to feel finished.

2500 assertions that nobody executes are not a weak proof. They are a document formatted like code. The number was doing the work that a green run should have been doing, and the number is the easiest thing in the world to produce.

Fixed and pushed: the crate is in the members list on main at Cargo.toml:44, and .github/workflows/ci.yml now exists, which it did not when this was audited. The side effect of the member fix is that cargo metadata --locked exits 0 again, because the published lock file had been left describing the private workspace.

What I did not check

My counts above are test attributes in the source, not tests executed. I have not run the suite on this machine, which has no Rust toolchain, so the last number I trust for pass counts is the ledger's.

Whether the other 2500 are worth keeping is a separate question I have only partly answered. A rough classification put around half of them in reach of a smaller end-to-end check, and about a quarter genuinely out of reach of one, tamper cases and signature paths among them. That classification was a reading, not a measurement, and I would not defend the percentages.

I also do not know how long the unreachable crate had been unreachable. The audit did not date it and I have not gone back through the history to find out.

Trace: the greps, the file paths and the presence of the workflow on main were checked on 2026-09-05.

Repository: TraceFold/tracefold, where tools/e2e.sh is the script that used to ship exiting 16.