Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test: deeplink connect native #14667

Merged
merged 5 commits into from
Oct 24, 2024
Merged

test: deeplink connect native #14667

merged 5 commits into from
Oct 24, 2024

Conversation

karliatto
Copy link
Member

@karliatto karliatto commented Oct 1, 2024

Description

Add new native e2e android test suite-native/app/e2e/tests/deeplinkPopup.test.ts where we call a @trezor/connect-mobile and get response in callback of a test server to check that we are getting the right response.

Related Issue

Related #14744

@karliatto karliatto force-pushed the test/deeplink-native branch from d24e263 to 4a03590 Compare October 1, 2024 21:34
@karliatto karliatto force-pushed the test/deeplink-native branch 5 times, most recently from f404274 to 0373f31 Compare October 7, 2024 09:45
@karliatto karliatto force-pushed the test/deeplink-native branch 13 times, most recently from cfc67fb to b94c7dc Compare October 21, 2024 08:21
@karliatto karliatto marked this pull request as ready for review October 21, 2024 09:06
@karliatto karliatto requested review from a team and vdovhanych as code owners October 21, 2024 09:06
@karliatto
Copy link
Member Author

I think this is ready.

@karliatto karliatto changed the title wip: test: deeplink connect native test: deeplink connect native Oct 21, 2024
Copy link
Contributor

@mroz22 mroz22 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good to me. just left 2 useless comments, feel free to ignore.

maybe just ask mobile guys if they want to have a look too? Or is @HajekOndrej interested here?

import { onCoinEnablingInit } from '../pageObjects/coinEnablingActions';
import { onHome } from '../pageObjects/homeActions';

const SERVER_PORT = 8080;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any chance that I would be running this locally while having connect-explrorer dev server active? I think that we are using this port somewhere already. clash is probably unlikely however.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I know connect-explorer is running on port 8088.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines 69 to 57
server.listen(SERVER_PORT, 'localhost', () => {
// eslint-disable-next-line no-console
console.info(`Server running at ${SERVER_URL}`);
});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nitpick: execution doesn't wait for server to be already listening. it could lead to a racecondition that is very unlikely to happen

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is a very good point. This should love that 9b9116f

Copy link
Contributor

@PeKne PeKne left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great idea to write an automated test for this. This will save us a lot of time debugging later if someone breaks the connect popup integration. 👏

.github/workflows/test-suite-native-e2e-android.yml Outdated Show resolved Hide resolved
packages/trezor-user-env-link/src/api.ts Show resolved Hide resolved
suite-native/app/e2e/tests/deeplinkPopup.test.ts Outdated Show resolved Hide resolved
suite-native/app/e2e/tests/deeplinkPopup.test.ts Outdated Show resolved Hide resolved
success: true,
};

await new Promise((resolve, reject) => {
Copy link
Contributor

@PeKne PeKne Oct 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is the Promise object needed here? What about simplifying it to something like:

Suggested change
await new Promise((resolve, reject) => {
if (JSON.stringify(response) !== JSON.stringify(expectedResponse)) {
new Error('Result does not match expected.')
}

Copy link
Member Author

@karliatto karliatto Oct 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@PeKne PeKne Oct 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This, unfortunately, does not work I tried to put a dummy value to the expectedResponse e.g. {success: false}, and the test still passed. It is because if the values do not match, an error object is created, but it is not thrown.

To ensure the values are compared correctly, you must use the jest assert function: expect (response).toEqual(expectedResponse). I am aware that I recommended you to use the Error object in the previous comment, but I was rather focusing on removing the Promise object.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, let's throw 407c5d0

expect does not work as expected, so I would keep the current approach but throwing the error, I tested with success and fail and it worked.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Strange, the expect worked for me locally. I like the expect keyword more because it prints out the difference between the two compared values in case of failure. Never mind, this works as well :).

@karliatto
Copy link
Member Author

@PeKne I responded to all your request and tests are still passing. Let me know!

@PeKne
Copy link
Contributor

PeKne commented Oct 23, 2024

Also one more thing. Now the test is working only for Android platform, but our tests are written for both Android and iOS. So it will always fail on Apple devices. For this reason, some platform condition should be introduced. ChatGPT offered me this solution (I tested it and it works):

...

// Define a function to conditionally skip or run the test suite
function conditionalDescribe(skipCondition: boolean, title: string, fn: jest.EmptyFunction) {
    if (skipCondition) {
        describe.skip(title, fn);
    } else {
        describe(title, fn);
    }
}

conditionalDescribe(device.getPlatform() !== 'android', 'Deeplink connect popup.', () => {
...

IMO it would make sense to put the conditionalDescribe to test utils in suite-common. It might be helpful later to someone else.

@mroz22
Copy link
Contributor

mroz22 commented Oct 23, 2024

IMO it would make sense to put the conditionalDescribe to test utils in suite-common. It might be helpful later to someone else.

this should be solved even more globally. we already use a custom conditionalTest in connect for example. cc @HajekOndrej

@martykan
Copy link
Member

I believe we can test iOS as well, it should work on both with the emulator.

@martykan
Copy link
Member

So I attempted to adjust the test for iOS, however there are some issues during onboarding and coin enabling, which block the progress of the test:

The app is busy with the following tasks:
• There are 1 work items pending on the dispatch queue: "Main Queue (<OS_dispatch_queue_main: com.apple.main-thread>)".
• 1 enqueued native timers:
- Timer #1:
    + Fire date: none.
    + Time until fire: 0.000.
    + Repeat interval: 0.
    + Is recurring: YES.
• Run loop "Main Run Loop" is awake. 

So overall the iOS E2E tests first need changes to support device connection.

@PeKne
Copy link
Contributor

PeKne commented Oct 23, 2024

@martykan We do not want to make iOS tests behave like Android devices. At the moment, the flows and UI are different between iOS and Android. So, it is not intended to make the tests do the same thing on both platforms. Thus, device connection should not be allowed for iOS e2e tests now until we introduce a Trezor device supporting Bluetooth.

@martykan
Copy link
Member

Ok, understandable, but currently all the iOS tests don't match the real behavior of the app.
When I build and run ios.sim.release tests, it's actually using the Debug variant, which supports connecting device and the flow is the same as Android.
Or maybe my setup is wrong?

@PeKne
Copy link
Contributor

PeKne commented Oct 23, 2024

@martykan Good point. We have not used iOS tests in CI until now, so it is highly possible that the iOS test does not behave as it should. However, soon, there will also be an iOS test run in CI, so it will need to be fixed.

Copy link
Contributor

@PeKne PeKne left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good job 👏

@karliatto karliatto force-pushed the test/deeplink-native branch from 9bce10c to 571e8da Compare October 24, 2024 06:35
@karliatto karliatto force-pushed the test/deeplink-native branch from 571e8da to e8feabe Compare October 24, 2024 06:43
@karliatto karliatto merged commit 84453a6 into develop Oct 24, 2024
88 checks passed
@karliatto karliatto deleted the test/deeplink-native branch October 24, 2024 07:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants