-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
fix: Fixed flaky test 24645 #25786
fix: Fixed flaky test 24645 #25786
Conversation
CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes. |
Why was the support page appearing? |
@danjm After seeing your comment, I wanted to attach a screenshot of the menu but found an interesting observation in the video attached. menu-item-change.movThe |
… fix-flaky-test-delete-network
… fix-flaky-test-delete-network
Builds ready [ebd025d]
Page Load Metrics (282 ± 290 ms)
Bundle size diffs
|
await driver.waitForSelector('[data-testid="global-menu-settings"]'); | ||
await driver.clickElement('[data-testid="global-menu-settings"]'); | ||
await driver.clickElement({ text: 'Networks', tag: 'div' }); |
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.
Should we just add timeout here since clickElement
has findElement
inside?
const element = await this.findClickableElement(rawLocator);
await element.click();
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.
Thanks, @DDDDDanica. That's a valid point about adding the timeout. This issue is happening only for the mmi build, and the menu item is changing. So, I have written a conditional wait for the menu in the code below. Let me know your thoughts.
if (process.env.METAMASK_BUILD_TYPE === 'mmi') {
await driver.wait(async () => {
const element = await driver.findVisibleElement(
'[data-testid="global-menu-mmi-portfolio"]',
);
if (!element) {
console.log('Element not visible');
}
}, 1000);
}
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.
@DDDDDanica, Thank you for the suggestion.
However, the initial use of waitForSelector but on the Portfolio Dashboard, combined with a conditional check is working effectively
Builds ready [67a3f7e]
Page Load Metrics (103 ± 32 ms)
Bundle size diffs
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #25786 +/- ##
========================================
Coverage 69.96% 69.96%
========================================
Files 1390 1390
Lines 48919 48919
Branches 13460 13460
========================================
Hits 34226 34226
Misses 14693 14693 ☔ View full report in Codecov by Sentry. |
@@ -113,12 +113,27 @@ const selectors = { | |||
|
|||
async function navigateToAddNetwork(driver) { | |||
await driver.clickElement(selectors.accountOptionsMenuButton); | |||
if (process.env.METAMASK_BUILD_TYPE === 'mmi') { | |||
await checkIfPortfolioDashboardIsVisible(driver); |
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.
The race-condition identified in this test can also affect other mmi tests: in all tests where we click the Settings icon '[data-testid="account-options-menu-button"]',
.
For this reason, we could have a generic function for checking if settings is ready, before proceeding with the next action.
We don't need to do this in this PR, but we could do it in the Page Object implementation, and having this guard for mmi builds can mitigate all flakiness related to the settings re-render case
cc @chloeYue
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.
Yes, I agree with you. We could do it in separate PR
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.
@seaona, I have introduced an additional wait for the portfolio dashboard and removed the checkIfPortfolioDashboardIsVisible function.
However, I believe this spec file is critical and contains many test cases that could be implemented using the Page Object Model. Do let me know what you think?
Also, this is completely different discuss and will leave it to @chloeYue
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.
yeah agree, POM will definitely help on this !
… fix-flaky-test-delete-network
… fix-flaky-test-delete-network
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.
one small nit, otherwise LGTM !
if (process.env.MMI) { | ||
await driver.waitForSelector('[data-testid="global-menu-mmi-portfolio"]'); | ||
} | ||
await driver.waitForSelector(selectors.settingsOption); |
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 line is not necessary, because we wait for element to be visible in clickElement
function.
@@ -66,7 +66,7 @@ const MOCK_CHAINLIST_RESPONSE = [ | |||
const selectors = { | |||
accountOptionsMenuButton: '[data-testid="account-options-menu-button"]', | |||
informationSymbol: '[data-testid="info-tooltip"]', | |||
settingsOption: { text: 'Settings', tag: 'div' }, | |||
settingsOption: '[data-testid="global-menu-settings"]', |
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 think this change is not strictly needed for fixing the issue, but I guess it's fine
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.
Actually, this locator strategy was sufficient, and with only this change, the CI has passed. However, I added an additional safety net to check for MMI and wait for the 'Portfolio Dashboard'.
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.
LGTM ! Good job !
… fix-flaky-test-delete-network
Quality Gate passedIssues Measures |
Builds ready [4386823]
Page Load Metrics (365 ± 312 ms)
Bundle size diffs
|
Description
This PR addresses a flaky test related to "Custom network Popular Networks List delete the Arbitrum network."
I was unable to reproduce the issue locally. However, after analyzing the CI screenshots, I identified the reason for the failure. The screenshot shows the support page appearing after the dropdown menu is displayed.
To resolve this, I have updated the test to click on the Settings using the
data-testid
attribute.Related issues
Fixes: #24645
Manual testing steps
Run locally or using codepsaces
yarn
yarn build:test:mmi
yarn test:e2e:single test/e2e/tests/network/add-custom-network.spec.js --browser=chrome --debug --leave-running
Pre-merge author checklist
Pre-merge reviewer checklist