Add mobile Maestro e2e scaffolding#953
Conversation
|
@olalois Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
📝 WalkthroughWalkthroughThis PR adds Maestro end-to-end test infrastructure for the mobile wallet app: a Maestro configuration file, four YAML flow specs (create-wallet, import-wallet, lock-unlock, send-payment), a manual-trigger CI workflow placeholder, and setup documentation covering env vars and run instructions. ChangesMobile Maestro E2E scaffolding
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant Maestro
participant WalletApp
Maestro->>WalletApp: launchApp
Maestro->>WalletApp: Create/Import wallet steps
WalletApp-->>Maestro: Assert wallet setup complete
Maestro->>WalletApp: Unlock with E2E_TEST_PASSWORD
WalletApp-->>Maestro: Assert Account screen
Maestro->>WalletApp: Send payment to E2E_RECIPIENT_ADDRESS
WalletApp-->>Maestro: Assert Transaction hash
Related issues: Related PRs: None identified Suggested labels: mobile, testing, ci Suggested reviewers: None identified 🐰 Hopping through flows, one tap at a time, 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
apps/mobile-wallet/e2e/flows/create-wallet.yaml (1)
4-4: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winFlow assumes fresh app state without explicit reset.
launchAppdoesn't guarantee a clean/unonboarded state by default; if this flow runs afterimport-wallet.yaml(or a prior run) in the same session/device, "Create a new wallet" may not be visible, causing a flaky failure. Consider usinglaunchApp: { clearState: true }(verify exact Maestro syntax) to ensure a deterministic starting state.♻️ Suggested reset guard
appId: org.ancore.wallet.dev --- # TODO: requires `#783` (mobile-wire-onboarding) — enable in CI after that ships -- launchApp +- launchApp: + clearState: true🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/mobile-wallet/e2e/flows/create-wallet.yaml` at line 4, The create-wallet flow currently starts with a plain launchApp, which can inherit a previously onboarded app state and make the “Create a new wallet” screen flaky. Update the flow to use the appropriate Maestro app reset option at startup (for example, launchApp with clearState enabled, if supported) so create-wallet.yaml always begins from a clean, deterministic state.apps/mobile-wallet/e2e/flows/lock-unlock.yaml (1)
3-4: 🩺 Stability & Availability | 🔵 Trivial | 🏗️ Heavy liftFlow has no setup step to guarantee an existing, onboarded wallet.
This flow launches the app and immediately expects "Unlock Wallet" to be visible, implicitly depending on a wallet already being created/imported from a prior flow run. Maestro flows are typically run independently, so this precondition isn't guaranteed — the flow will fail if run standalone or before
create-wallet/import-wallet. Consider chaining a setup step (e.g.,runFlow: import-wallet.yaml) or documenting the required precondition/ordering explicitly.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/mobile-wallet/e2e/flows/lock-unlock.yaml` around lines 3 - 4, The lock-unlock Maestro flow assumes a pre-existing onboarded wallet because it goes straight from launching the app to tapping “Unlock Wallet.” Update the flow to either set up the wallet first by chaining a setup flow such as import-wallet.yaml (or create-wallet.yaml) before the unlock step, or explicitly document the required precondition/order for lock-unlock so it can run reliably. Use the lock-unlock.yaml flow and its launchApp/tapOn sequence as the place to add the dependency.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/mobile-e2e.yml:
- Around line 11-12: The Checkout repository step in the mobile-e2e workflow is
leaving the GitHub token persisted in git config; update the actions/checkout@v4
usage to disable credential persistence. Modify the checkout configuration for
that step to set persist-credentials to false so the token is not retained for
the rest of the job.
---
Nitpick comments:
In `@apps/mobile-wallet/e2e/flows/create-wallet.yaml`:
- Line 4: The create-wallet flow currently starts with a plain launchApp, which
can inherit a previously onboarded app state and make the “Create a new wallet”
screen flaky. Update the flow to use the appropriate Maestro app reset option at
startup (for example, launchApp with clearState enabled, if supported) so
create-wallet.yaml always begins from a clean, deterministic state.
In `@apps/mobile-wallet/e2e/flows/lock-unlock.yaml`:
- Around line 3-4: The lock-unlock Maestro flow assumes a pre-existing onboarded
wallet because it goes straight from launching the app to tapping “Unlock
Wallet.” Update the flow to either set up the wallet first by chaining a setup
flow such as import-wallet.yaml (or create-wallet.yaml) before the unlock step,
or explicitly document the required precondition/order for lock-unlock so it can
run reliably. Use the lock-unlock.yaml flow and its launchApp/tapOn sequence as
the place to add the dependency.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: af4be9e2-2708-495e-bf91-77c4b766d5b9
📒 Files selected for processing (7)
.github/workflows/mobile-e2e.ymlapps/mobile-wallet/e2e/flows/create-wallet.yamlapps/mobile-wallet/e2e/flows/import-wallet.yamlapps/mobile-wallet/e2e/flows/lock-unlock.yamlapps/mobile-wallet/e2e/flows/send-payment.yamlapps/mobile-wallet/maestro.config.yamldocs/testing/mobile-e2e-setup.md
| - name: Checkout repository | ||
| uses: actions/checkout@v4 |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win
Disable credential persistence on checkout.
Static analysis flags this checkout step for not setting persist-credentials: false, leaving the GitHub token persisted in the git config for the remainder of the job.
🔒 Proposed fix
- name: Checkout repository
uses: actions/checkout@v4
+ with:
+ persist-credentials: false📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - name: Checkout repository | |
| uses: actions/checkout@v4 | |
| - name: Checkout repository | |
| uses: actions/checkout@v4 | |
| with: | |
| persist-credentials: false |
🧰 Tools
🪛 zizmor (1.26.1)
[warning] 11-12: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/mobile-e2e.yml around lines 11 - 12, The Checkout
repository step in the mobile-e2e workflow is leaving the GitHub token persisted
in git config; update the actions/checkout@v4 usage to disable credential
persistence. Modify the checkout configuration for that step to set
persist-credentials to false so the token is not retained for the rest of the
job.
Source: Linters/SAST tools
2 participants
Summary
Closes #786
Summary by CodeRabbit
New Features
Documentation