Mistakes fail the build

Before any program runs, a tool called a compiler reads the code and checks it. We write our code so that this check knows a great deal about the project. It knows which pages exist, which parts of a page can be updated, and which permissions a user can hold. When something does not fit, the code does not build and nobody can ship it.

Some mistakes only show up once the program starts. For those, the program checks itself at startup and refuses to run. On Planet Positive Sport a missing file store stops the server on the spot. Everything the first two checks cannot reach gets an automated test, written to fail loudly and to say exactly what went wrong.

• A misspelled permission on Planet Positive Sport, such as "assesments:read", does not build
• A missing file store stops the platform at startup, before any user can reach it
• A changed scoring value fails a test that names it

Planet Positive Sport is the platform FIVB uses to certify the environmental footprint of volleyball events. An event qualifies at 2.61. A careless edit to one number in the scoring method could move real events across that line, and nobody would notice until a report was wrong.

So every value and rounding step in the method is recorded under the method's version name. A test compares the live method with that record on every run. Change a value without declaring a new version and the test fails, printing the value that moved, what it was, and what it became. Earlier versions stay recorded too, so the test file also shows how every past version scored.

When the method was replaced in July, a script scored every live event under the old rules and the new ones. It listed the events whose result changed enough to matter. That list went to the client before the change shipped.

Our web pages often update one part of the screen without reloading the whole page. The piece of code that asks for the update names its target, and the server sends back a piece of page carrying that name. If the two names drift apart, the button quietly does nothing, and nobody notices until a user does.

In fluent-html, our own library for writing web pages, the name of each target travels with the code that uses it. A request aimed at a name the reply never contains fails the build, and the error names both of them. On fluent-html.com anyone can click through 36 combinations and six broken setups and read the real error for each, with no script running on the page.

A rule written down in two places will eventually say two different things. On GZS Inovacije, Slovenia's national innovation awards, the weighted formula that scores each entry lives in one file. The same formula feeds the official total and the preview a judge sees while typing, so the two cannot disagree.

Where copies have to exist, a drift test watches them. That is an automated check that compares the copies on every build and fails the moment they differ. In fluent-html one table of about 120 rows generates the styling methods, a tool that collects the styles each page uses, and a set of 32 code-checking rules. Tests fail the build if any of them stops matching the table.

None of this makes software perfect, and we write down when it falls short. The fluent-html changelog says plainly that one feature passed every check and still did nothing in the browser for a while. That note is there for anyone to read.