Automation
Four more harnesses
Once the Music Mode harness worked, I applied the same approach to the rest of the platform. Each harness starts from one plain question, and each ends with a report a non-developer can read.
| Harness | Cases | Sections | The question it answers |
|---|---|---|---|
| Ad scheduler | 154 | 15 | Does the box do what the schedule says? |
| v3 box | 115 | 10 | Is this box fit to ship? |
| 3.1 audio interface | 75 | 8 | Does sound go where it should, at every layer? |
| Stadium Squares game | 160 | 18 | Does the live game hold up with real players? |
Harness 1
The ad scheduler
The scheduler decides which ads and content play, and when. It is where a small error shows up as the wrong ad at the wrong time, or two schedules fighting for the same slot.
The harness runs 154 cases in 15 sections against real box behavior. It covers schedule creation, conflict and reconciliation cases, and command dispatch. Failures arrive with logs, and the suite runs on demand and in CI. It has its own operational guide, case catalogue, runbook, test-record template, and support document.
Harness 2
The v3 box: "is this box fit to ship?"
v3 is the newest hardware generation. Before a box leaves the bench, someone has to know it is healthy. The harness answers that with a pass/fail report for each box.
It works through the supervisor command-line tool, container inspection, the MQTT bus, and the logs. In several sections it also breaks things on purpose and watches whether the box recovers. It checks deployment compatibility, software and service version compatibility, hardware configuration, and hardware faults.
| Section | Cases |
|---|---|
| A. Preflight | 34 |
| B. Service cycle | 15 |
| C. Ad path | 10 |
| D. Display and routing | 5 |
| E. Detection | 5 |
| F. Safe mode | 10 |
| G. Data layer | 10 |
| H. Content and scheduling | 11 |
| I. Other containers | 13 |
| J. Content chain, end to end | 2 |
Modes. A proof mode shows that the checks themselves can fail. Read-only probes inspect a live box without changing it. A soak mode runs for a set number of hours at a set interval, samples memory, swap, and other metrics, and reports the trend, which is how slow leaks and creeping pressure show up. Nine of the cases are marked slow.
Harness 3
The 3.1 audio interface
The 3.1 interface is USB audio hardware that carries music and ad sound to the venue. Audio bugs are hard because there are four places a signal can go wrong, and "no sound" tells you none of them.
So the harness tests four layers separately: the interface, the mixer, the audio itself (using a measured test signal, not an assumption), and the application on top. It has 75 cases in 8 sections and 121 self-tests, and it runs on a bench box with a studio-grade USB interface. It includes a proof mode, hands-on sections that need a person at the bench, and fragility sections that stress the setup.
Nothing from the test rig goes toward an amplifier. The suite produced 16 findings.
Harness 4
Stadium Squares, a live patron game
Stadium Squares is a live venue game that patrons join from their phones with a room code. A bug here shows up in front of a full bar.
The harness has 160 cases in 18 sections and 38 commands. It runs from a laptop against staging and production. 147 cases are proven, and eleven are expected failures that encode known findings, so each one turns green the day its bug is fixed. It also includes a 50-patron load test and a lifecycle run of up to 14 hours.
It found 11 problems, 5 of them in access control. Those are covered on the security page. It also checked the part that matters most to players: win calculation. That held up.
load 50 patrons joined, cards generated PASS play calls issued, wins claimed PASS win logic pattern checks across all win types PASS expected known finding, still open XFAIL soak hour 14 of 14, memory flat PASS