-
Notifications
You must be signed in to change notification settings - Fork 5k
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
Multichain E2E Test: Multi dapp #29751
base: jl/caip-multichain-migrate-core
Are you sure you want to change the base?
Multichain E2E Test: Multi dapp #29751
Conversation
if (!multipleDapps) { | ||
await unlockWallet(driver); | ||
} | ||
await openDapp(driver, undefined, 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.
I'm not a big fan of this extra 4th (optional) param, but I needed this util function to only unlock the wallet once for a multi dapp setup. So in the actual test we call unlockWallet
once, and then loop through dapps to actually open the dapps themselves.
Should we make another util func that's used for multi dapp setup, or other suggested approaches, or ya'll fine with this ?
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.
I would just move the unlockWallet
step out of this method entirely. It's not uncommon in the e2e specs to see a call to unlockWallet() as the first step. I agree with your thinking that adding this multipleDapps
optional param is weird
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 would require going through every other current multichain dapp e2e existing test and adding in await unlockWallet(driver);
are you okay with doing that ?
|
||
// Assert | ||
for (const [i, dapp] of DAPP_URLS.entries()) { | ||
const accountWebElement = await driver.findElement( |
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.
Multiple loops because we want to make sure we queue up all the requests first, and then make assertions that the sequence of requests, the origin and account are correct for each confirmation in the queue (as per ticket description)
Builds ready [ee1029b]
Page Load Metrics (1655 ± 64 ms)
|
dappPath: path.join( | ||
'..', | ||
'..', | ||
'node_modules', | ||
'@metamask', | ||
'test-dapp-multichain', | ||
'build', | ||
), |
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.
did we have a constant for this somewhere already?
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.
We had a constant for this for single dapp setup, it's slightly different for multi dapp setup
await initCreateSessionScopes(driver, [SCOPE], ACCOUNTS); | ||
await addAccountInWalletAndAuthorize(driver); | ||
await driver.clickElement({ text: 'Connect', tag: 'button' }); | ||
await driver.delay(largeDelayMs); | ||
await driver.switchToWindowWithUrl(dapp); |
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 this create session necessary given the fixtures?
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.
removed in 9638656, does not seem necessary for read operations test
await initCreateSessionScopes(driver, [SCOPE], ACCOUNTS); | ||
await addAccountInWalletAndAuthorize(driver); | ||
await driver.clickElement({ text: 'Connect', tag: 'button' }); |
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.
same question about if this manual connection is needed since the fixture includes accounts
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.
If I don't manually create sessions in this second one, when calling eth_sendTransaction
downstream the wallet extension UI is not popping up for some reason, causing the test to fail 🤔
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 one seems quite flaky, it's sometimes failing on CI (but passing locally) with a StaleElementReferenceError: stale element reference: stale element not found in the current frame
which is weird. I may need to re-visit this implementation for a more consistent reliable approach
test/e2e/flask/multichain-api/multi-dapp-wallet_invokeMethod.spec.ts
Outdated
Show resolved
Hide resolved
Builds ready [ea96578]
Page Load Metrics (1605 ± 69 ms)
|
-- test: multi dapp e2e test setup;
Description
Related issues
Fixes:
Manual testing steps
Screenshots/Recordings
Before
After
Pre-merge author checklist
Pre-merge reviewer checklist