How We Test
Counts recounted directly from the code and test files on August 30, 2026 — not copied from an old document. They are recomputed on every release by npm run test:how-we-test-counts, which fails the build if this page and the tree disagree.
A stage plot app is judged on one thing: does the file load on the desk. Everything on this page exists to answer that question honestly, including the parts that aren't finished yet. If a comment thread wants to argue about whether this is "AI slop," this is the page — judge the files, not the pitch.
Automated checks, every time the code changes
Before a release ships, the code runs through 156 separate automated checks — one command, chained end to end. That includes file-safety checks, a check that scans every public page for over-claiming language before it can go out, checks that every one of the eleven in-app languages has real translations instead of English leaking through, and a dedicated check per supported console format that a file written by load·in opens back up cleanly and only the fields it's supposed to touch actually changed.
Underneath that chain sit 220 dedicated test files for the console and DAW export engines alone, plus another 11 covering account, billing, and file-transfer behavior. Each one is a small, focused check — export this file, open it again, confirm only the intended fields moved and everything else came through untouched.
Per-console coverage
Some desks have deeper coverage than others because they've been in the app longer or their file format has more moving parts. Every console family in the app has its own dedicated tests, and a lot of shared logic — the parts every format runs through, like channel renumbering and file-safety refusal — gets its own tests on top, so coverage runs deeper than any per-desk list would suggest. Where a desk's coverage is thinner, its export preview says so in plain language rather than letting the gap hide.
The app also keeps its own internal ledger of exactly which fields are tested for which format — 43 tracked entries — and a release can't ship if that ledger and the actual code disagree.
Interface tests, on a real browser engine
Console files are only half the job — the other half is not losing your work while you're dragging a drum kit around on a phone at 6am. 560 browser-driven interface tests across 139 files run the app the way a person actually would: touch targets on a phone screen, dense stage plots with a lot of overlapping elements, saving a project and opening it again, 2D and 3D view switching, and deleting the right element instead of the one next to it.
Formal models for the parts that are easy to get wrong by hand
Three parts of load·in are checked with a formal mathematical model in addition to ordinary tests: cross-device sync conflict resolution, the show-timer state machine in change·over, and the invoicing state machine in gain·stage. This method exists to catch edge cases in state logic that are easy to miss by hand-testing — it does not cover the console file formats themselves, which are verified the way every claim on this page describes: by building the file and checking it.
Files loaded on real console hardware
Automated checks prove the code does what it's supposed to do. They don't prove a physical console will open the file. For that there's only one real test, and it's been run: files built with load·in have been loaded onto physical Yamaha CL1, Behringer X32, and Allen & Heath dLive console hardware — not just the manufacturer's desktop editor, the actual desk. Channel names and the enabled state landed correctly. Every export screen states plainly which fields are backed by hardware testing, which are backed by the manufacturer's official editor software, and which are still names-only — see the export preview for the exact scope on the desk you're using.
What the export screen actually tells you
Every export sorts what changed into three groups, with channel numbers, right before the file is written:
- Confirmed — tested and, where hardware or the manufacturer's editor is available, checked there too.
- Verify — the app wrote it, but you should confirm it at the desk before a show that matters.
- Unsupported — the selected format doesn't carry this field, so it's left alone.
Nothing lands in a fourth, unlabeled bucket. That's the whole point of testing this hard — so the app can tell you the truth in three words instead of hedging in a paragraph.
What this page is not
It's not a claim that every field on every desk is covered — it isn't, and the export preview for your specific desk is the actual source of truth on any given day, not this page. It's not a claim that automated tests replace checking your file before a show — see the app itself, which says the same thing at export time. It's a plain accounting of what actually runs, so you can decide for yourself whether that's enough to trust with your gig.
load·in is independent interoperability software; all console names and trademarks are property of their respective owners — see the Trademark Notice.