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

Multichain E2E Test: Multi dapp #29751

Open
wants to merge 13 commits into
base: jl/caip-multichain-migrate-core
Choose a base branch
from

Conversation

ffmcgee725
Copy link
Member

@ffmcgee725 ffmcgee725 commented Jan 16, 2025

-- test: multi dapp e2e test setup;

Description

Open in GitHub Codespaces

Related issues

Fixes:

Manual testing steps

  1. Go to this page...

Screenshots/Recordings

Before

After

Pre-merge author checklist

Pre-merge reviewer checklist

  • I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
  • I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

if (!multipleDapps) {
await unlockWallet(driver);
}
await openDapp(driver, undefined, url);
Copy link
Member Author

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 ?

Copy link
Contributor

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

Copy link
Member Author

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(
Copy link
Member Author

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)

@ffmcgee725 ffmcgee725 requested a review from adonesky1 January 17, 2025 16:22
test/e2e/fixture-builder.js Outdated Show resolved Hide resolved
@ffmcgee725 ffmcgee725 requested a review from jiexi January 17, 2025 23:44
@metamaskbot
Copy link
Collaborator

Builds ready [ee1029b]
Page Load Metrics (1655 ± 64 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint14552136166114469
domContentLoaded14382062164013264
load14462073165513464
domInteractive247240178
backgroundConnect85718147
firstReactRender15104392914
getState45412157
initialActions00000
loadScripts10361519118210550
setupStore570172010
uiStartup16372393198419795

Comment on lines +35 to +42
dappPath: path.join(
'..',
'..',
'node_modules',
'@metamask',
'test-dapp-multichain',
'build',
),
Copy link
Contributor

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?

Copy link
Member Author

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

Comment on lines 83 to 87
await initCreateSessionScopes(driver, [SCOPE], ACCOUNTS);
await addAccountInWalletAndAuthorize(driver);
await driver.clickElement({ text: 'Connect', tag: 'button' });
await driver.delay(largeDelayMs);
await driver.switchToWindowWithUrl(dapp);
Copy link
Contributor

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?

Copy link
Member Author

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

Comment on lines +152 to +154
await initCreateSessionScopes(driver, [SCOPE], ACCOUNTS);
await addAccountInWalletAndAuthorize(driver);
await driver.clickElement({ text: 'Connect', tag: 'button' });
Copy link
Contributor

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

Copy link
Member Author

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 🤔

Copy link
Member Author

@ffmcgee725 ffmcgee725 Jan 30, 2025

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

@metamaskbot
Copy link
Collaborator

Builds ready [ea96578]
Page Load Metrics (1605 ± 69 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint13791908160314067
domContentLoaded13741858158513364
load13791910160514569
domInteractive24103432311
backgroundConnect75422168
firstReactRender15100452914
getState47114189
initialActions01000
loadScripts9801395115412057
setupStore66712168
uiStartup15772254185520498

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants