-
-
Notifications
You must be signed in to change notification settings - Fork 266
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
Conversation
d24e263
to
4a03590
Compare
f404274
to
0373f31
Compare
cfc67fb
to
b94c7dc
Compare
I think this is ready. |
There was a problem hiding this 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; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
right, I saw it here https://github.com/trezor/trezor-suite/blob/develop/docs/features/coinjoin.md#L15
server.listen(SERVER_PORT, 'localhost', () => { | ||
// eslint-disable-next-line no-console | ||
console.info(`Server running at ${SERVER_URL}`); | ||
}); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this 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. 👏
success: true, | ||
}; | ||
|
||
await new Promise((resolve, reject) => { |
There was a problem hiding this comment.
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:
await new Promise((resolve, reject) => { | |
if (JSON.stringify(response) !== JSON.stringify(expectedResponse)) { | |
new Error('Result does not match expected.') | |
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 :).
@PeKne I responded to all your request and tests are still passing. Let me know! |
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 |
this should be solved even more globally. we already use a custom conditionalTest in connect for example. cc @HajekOndrej |
I believe we can test iOS as well, it should work on both with the emulator. |
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:
So overall the iOS E2E tests first need changes to support device connection. |
@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. |
Ok, understandable, but currently all the iOS tests don't match the real behavior of the app. |
@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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good job 👏
9bce10c
to
571e8da
Compare
571e8da
to
e8feabe
Compare
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