From 224 to 621: how a red test run turned green on one laptop

On 25 September 2026 the project laptop was 45 commits behind the main branch. The first full test run was poor: 224 tests passed and about 100 either failed or could not even start. By the seventh run 621 passed and nothing failed. This post is about how, because the story is more useful than the number.

The first surprise was that the second run got worse. A fresh Python environment had been created with only four packages, and the system Python it replaced had many more. Dozens of tests that had been passing now failed on a missing import, not on a bug. Installing the agent requirements brought the count back up to 565, adding the web client took it to 605, and the database drivers lifted it further. Adding the machine-learning packages left the count at 616. The last run, at 621, followed a single test fix and the database migrations.

That single code-level failure was a test written when the satellite handlers were hard-coded in one file. The code had since moved to a registry, so the test was simply updated to look there. No product behaviour changed.

The lesson we wrote down is practical. Most of the red was the environment, not the code, and a test count means little unless the environment it ran in is written down too. That is why every laptop update in our status document says exactly what to install and what to restart. You can see the current state of the checks on the status page.

This was a development exercise. Africa Flying is pre-operations, simulation-only software, and none of these tests involves a real aircraft.

Read next

• 7,444 places: the data catalog audit from 24 September.
• September in plain terms: the whole month at a glance.
• One day, thirteen agents: where hundreds of those tests came from.

The detail chart

All seven runs, passed against failed plus errored. Secondary to the story above.

Sources and credits

• pytest: the Python test runner that produced the counts.