test(suite-native): receive flow e2e test added #17264
Conversation
WalkthroughThe changes enhance the "Receive" functionality by adding both new actions and testing support. A new asynchronous method is introduced to interact with the receive UI element, and a dedicated actions class is created to encapsulate behaviors such as waiting for the receive screen, clicking the address button, and verifying the displayed address. Complementing these actions, an end-to-end test specifically for Android devices has been added, which simulates the complete user journey including emulator setup, onboarding bypass, network and asset navigation, and verifying receive address outcomes. Additionally, UI components now include extra identifiers (via Tip CodeRabbit's docstrings feature is now available as part of our Pro Plan! Simply use the command ✨ Finishing Touches
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (5)
suite-native/app/e2e/pageObjects/accountReceiveActions.ts (2)
3-3: Class naming should use PascalCase.The class name uses camelCase (
accountReceiveActions) which is inconsistent with other action classes in the codebase that use PascalCase (likeAccountDetailActions).-class accountReceiveActions { +class AccountReceiveActions {
26-26: Update exported instance name to match class name.If you update the class name to PascalCase, make sure to update the exported instance name as well for consistency.
-export const onAccountReceive = new accountReceiveActions(); +export const onAccountReceive = new AccountReceiveActions();suite-native/app/e2e/tests/receive.test.ts (3)
14-14: Consider documenting why this test is Android-specific.The
conditionalDescribelimits execution to Android platforms, but there's no explanation why. If there are platform-specific behaviors or limitations, adding a brief comment would help other developers understand the test's scope.
33-36: Replace hardcoded address with a dynamic expectation.The test verifies against a hardcoded address (
bc1qa55m6kz3crfse5xg2rukulyap4eyp75w0puawz), which could make the test brittle if addresses change due to emulator resets or configuration changes.Consider either:
- Retrieving the expected address dynamically from the Trezor emulator
- Using address pattern validation instead of exact matching
- Adding a comment explaining why this specific address is used
- await onAccountReceive.verifyReceiveAddress('bc1qa55m6kz3crfse5xg2rukulyap4eyp75w0puawz'); + // Example of dynamic address retrieval (implementation would depend on your architecture) + const expectedAddress = await TrezorUserEnvLink.getFirstAvailableAddress('btc'); + await onAccountReceive.verifyReceiveAddress(expectedAddress);
37-37: Consider adding error handling for disconnection.The disconnect operation lacks error handling. If the disconnection fails, the test might not clean up properly.
- disconnectTrezorUserEnv(); + try { + await disconnectTrezorUserEnv(); + } catch (error) { + console.error('Failed to disconnect Trezor user environment:', error); + // Consider whether to fail the test or just log the error + }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
suite-native/app/e2e/pageObjects/accountDetailActions.ts(1 hunks)suite-native/app/e2e/pageObjects/accountReceiveActions.ts(1 hunks)suite-native/app/e2e/tests/receive.test.ts(1 hunks)suite-native/qr-code/src/components/AddressQRCode.tsx(1 hunks)suite-native/receive/src/components/ShowAddressButtons.tsx(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: prepare_android_test_app
- GitHub Check: Setup and Cache Dependencies
- GitHub Check: Analyze with CodeQL (javascript)
🔇 Additional comments (8)
suite-native/app/e2e/pageObjects/accountDetailActions.ts (1)
19-22: Excellent addition of the openReceive method.The implementation follows the same pattern as the existing openSend method, maintaining consistency in the codebase.
suite-native/receive/src/components/ShowAddressButtons.tsx (1)
40-45: Good testability improvement with testID addition.Adding the testID to the Button component enhances the component's testability without changing any functionality, which is exactly what we want for E2E testing support.
suite-native/qr-code/src/components/AddressQRCode.tsx (1)
42-46: Well-implemented testID for address verification.Adding the testID to this Text component is essential for the E2E test to verify the displayed address. Good implementation that doesn't affect the component's core functionality.
suite-native/app/e2e/pageObjects/accountReceiveActions.ts (2)
8-16: Good implementation of button interaction with appropriate timeouts.The method properly waits for the button to become visible with a reasonable timeout, taps it, and then verifies that it's no longer visible after the interaction. This ensures that the test will correctly handle any delays in the UI rendering.
18-23: Well-structured address verification method.This method appropriately waits for the address text to be visible and then verifies that it matches the expected address. The 30-second timeout provides adequate flexibility for device confirmation processes.
suite-native/app/e2e/tests/receive.test.ts (3)
1-13: Well-structured imports and dependencies.The imports are well-organized, clearly separating test utilities, page objects, and helper functions.
15-29: Test flow is clear and follows best practices.The test follows a logical progression:
- Setting up the emulator and application
- Configuring the environment (enabling Bitcoin network)
- Navigating to the relevant screen
This organization makes the test easy to understand and maintain.
30-32: Good separation of concerns with page objects.Using dedicated page objects (
onAccountDetailandonAccountReceive) for different screens follows best practices for E2E testing, improving maintainability and reusability.
Description