test: wait for spending confirm after advanced continue

[piotr-iohk]

Summary

• Wait for Spending Confirm after SpendingAdvancedContinue instead of a 500ms sleep, matching the amount-screen continue already used later in @transfer_1.
• Unblocks bitkit-ios#686: the affordability re-check before createOrder pushed that transition past the old sleep, so Back could pop Advanced before dismiss() and desync the nav stack (see comment).
• Same branch name as the product PR so iOS CI resolves this e2e branch automatically.

Test plan

• @transfer_1 on iOS against fix/spending-transfer-affordability (bitkit-ios#686)
• @transfer_1 on Android (wait is a no-op when Confirm is already up)

Made with Cursor

[jvsena42]

Thanks for picking this up 🙏 — the waits are the right call, and the app-side latency fix landed too, so the original drift is gone (the → SpendingAmountMax not found, navigating back line no longer appears, and the Advanced Continue transition is down from ~1.4s to ~1s).

@transfer_1 is still failing though, now on the new wait at line 105:

Error: element ("~SpendingConfirmAdvanced") still not displayed after 30000ms

bitkit-ios run 33904122187, attempt 3. The recorded video shows the app arriving at the confirm screen ~1s after the tap and sitting there for the remaining 25s of the timeout — so it isn't a timing problem. The screen it lands on has Learn More | Use Defaults, i.e. SpendingConfirmDefault.

Reason: SpendingAdvancedContinue creates an advanced order, which flips isAdvanced, and the confirm screen swaps that button's identifier:

// bitkit-ios SpendingConfirm.swift:107-116
if transfer.uiState.isAdvanced { … .accessibilityIdentifier("SpendingConfirmDefault") }
else                           { … .accessibilityIdentifier("SpendingConfirmAdvanced") }

Android does the same thing, so this would fail there too:

// bitkit-android SpendingConfirmScreen.kt:266
if (isAdvanced) "SpendingConfirmDefault" else "SpendingConfirmAdvanced"

Worth flagging since Android CI is green on this: determine-e2e-branch.yml resolves the e2e branch by app-branch name, and there's no fix/spending-transfer-affordability in bitkit-android, so that run fell back to main — the old sleep(500) version. It passes there because Android's Continue was never the slow one. So the green Android run isn't exercising this PR.

The fix is one word at line 105, matching what you already have at 182/193/204:

 await tap('SpendingAdvancedContinue');
-await elementById('SpendingConfirmAdvanced').waitForDisplayed();
+await elementById('SpendingConfirmDefault').waitForDisplayed();
 await tap('NavigationBack');

Lines 119 and 129 look right as they are — both follow SpendingAmountContinue, which resets isAdvanced to false, so SpendingConfirmAdvanced is the correct identifier there.

[piotr-iohk]

Yep — SpendingConfirmDefault after Advanced Continue was the right wait. Landed that.

Once Confirm is actually up, a single Back still missed Amount on iOS (the old Max catch was covering it). backToSpendingAmount() waits for Amount and retries Back only on iOS — a second Back on Android leaves the amount screen and Continue submits 0.

Also waiting for the Advanced screen after SpendingConfirmAdvanced instead of sleep(500).

Local @transfer_1 is green on both. Re-ran the iOS shard: https://github.com/synonymdev/bitkit-ios/actions/runs/33904122187?pr=686