How we know something actually works

A build that compiles is not a feature that works. Most of the bugs that reach production got there because somebody, reasonably, treated a clean exit code as evidence. These are the checks we run instead.

Exercise the thing, not the code path near it

When we connected the contact form to an API, the temptation was to read the handler, agree it looked right, and move on. Instead we posted through it: empty fields, a malformed email, a body over the length cap, a bot filling the hidden field, and one genuine message.

Each returned what it should, and the real one came back with an identifier from the API — proof that a record existed rather than a belief that one probably did.

The valuable case was one we would not have thought to reason about. With a deliberately invalid destination configured, the endpoint reached the API, received a real not-found error, logged the detail, and returned a generic failure to the browser. That single test confirmed the outbound call, the error handling, and the fact that upstream detail was not leaking to visitors.

Prove the negative

Some requirements are about what must not happen, and those need their own test because nothing fails when they are broken.

A secret key must not reach the browser. We satisfied that by building the site with a fake secret in place and searching the output bundle for it. Absent, as intended — while the deliberately public value was present, also as intended. Reasoning about which variables get bundled is not the same as checking.

Worth noting how that check first misfired: a naive search matched the string in a code comment and reported a leak that did not exist. A test that cries wolf is nearly as bad as no test, so it was tightened to match the shape of an actual key.

Assert the invisible

The prerender step writes a static HTML file per route. Its failure mode is silent: a route that renders nothing still produces a file, and the build still succeeds.

So it asserts. After each route it strips the tags, counts the text, and throws if the page came out near-empty. It also throws if the template lacks the element the content is injected into. A build that stops loudly beats one that ships a blank page while reporting success.

Distrust your own machine

Two false alarms, both from local state rather than the system under test.

After the custom domain went live, this machine could not resolve it while public resolvers answered correctly. The cause was a cached negative lookup from before the record existed. The site was fine; the computer asking was wrong.

Immediately after a first deploy, every request returned a gateway error. That reads like a broken release. It was propagation, and it cleared in about a minute.

In both cases the honest check was to go around the local machine: query a public resolver directly, or request the origin with an explicit host header. If you only ever test from one machine, you cannot tell a broken deployment from a stale cache.

Say what you did not check

Some things genuinely cannot be verified from here. Whether a public API key works from an allowlisted origin needs a real key and a registered origin; we could observe that an unregistered origin gets no permission headers, and no more than that.

Reporting that as working would have been a guess wearing the costume of a result. The useful version is narrower and more honest: here is what was confirmed, here is what was not, and here is the fallback if the unconfirmed part behaves differently.