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

fix: flaky test ERC1155 NFTs testdapp interaction should batch transfers ERC1155 token #27897

Merged
merged 1 commit into from
Oct 16, 2024

Conversation

seaona
Copy link
Contributor

@seaona seaona commented Oct 16, 2024

Description

Same problem as #27889.

We are looking for transactions by its text in the activity tab, but the transaction element updates its state, from pending to confirm, meaning that it can become stale when we do the assertion after.

await driver.waitForSelector({
          css: '[data-testid="activity-list-item-action"]',
          text: 'Deposit',
});
assert.equal(await transactionItem.isDisplayed(), true);

Screenshot from 2024-10-16 12-05-08

Open in GitHub Codespaces

Related issues

Fixes: #27896

Manual testing steps

  1. Check ci

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.

@seaona seaona added team-extension-platform flaky tests area-qa Relating to QA work (Quality Assurance) labels Oct 16, 2024
@seaona seaona self-assigned this Oct 16, 2024
@seaona seaona requested a review from a team as a code owner October 16, 2024 10:05
Copy link
Contributor

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.

await transactionItem.isDisplayed(),
true,
`transaction item should be displayed in activity tab`,
);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

this is an anti-pattern, that causes the race condition, when we do the assert if the element is updated (from pending to confirmed)

await transactionItem.isDisplayed(),
true,
`transaction item should be displayed in activity tab`,
);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

anti-pattern

const displayedDescription = await driver.findElement(
'.confirm-approve-content__description',
);
assert.equal(await displayedDescription.getText(), expectedDescription);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

all these above are anti-patterns

Copy link
Contributor

Choose a reason for hiding this comment

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

Do you think we could write a regular expression (or a piece of code in general) to detect this anti-pattern? Because then we could write a lint rule for it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

whoa I think that is worth investigating, as this anti-pattern is re-introduced over and over in our tests unfortunately :( Despite having this documented as an anti-pattern. I can create a ticker for this.
Would it be something like: forbid anything in the form of assert.equal(await something.getText(), something)

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm you're thinking of a much simpler test than I was thinking of. I was thinking of considering the findElement part too. I think no matter what we write, there's going to be false positives and false negatives. There are times when assert.equal(await something.getText(), something) is actually the correct solution. But I guess we can force an eslint-disable-next-line in those cases.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ℹ️ as info, we have this ticket which reflects the work of removing this anti-pattern, and we've been adding some fixes around that:

#19870

In parallel, adding this lint rule (if it's possible) could make that no more new tests are using this pattern anymore

Copy link
Contributor Author

@seaona seaona Oct 16, 2024

Choose a reason for hiding this comment

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

I was thinking of considering the findElement part too. I think no matter what we write, there's going to be false positives and false negatives. There are times when assert.equal(await something.getText(), something) is actually the correct solution

oh that is a really good point! Yeah maybe the rule needs to be a bit more elaborated indeed, otherwise we'll be force to disable lint in legit occasions, as you mention 🤔

const displayedDescription = await driver.findElement(
'.confirm-approve-content__description',
);
assert.equal(await displayedDescription.getText(), expectedDescription);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

anti-patterns

css: '.transaction-list__completed-transactions',
text: 'Approve Token with no spend limit',
});
assert.equal(await revokeApprovalItem.isDisplayed(), true);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

anti-pattern

Copy link

sonarcloud bot commented Oct 16, 2024

@metamaskbot
Copy link
Collaborator

Builds ready [7a40481]
Page Load Metrics (1969 ± 131 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint168425941960259125
domContentLoaded167024351913219105
load168026651969274131
domInteractive15189573919
backgroundConnect10315557134
firstReactRender54167982713
getState5157263617
initialActions01000
loadScripts12141919143618287
setupStore11149413517
uiStartup187135702240417200
Bundle size diffs
  • background: 0 Bytes (0.00%)
  • ui: 0 Bytes (0.00%)
  • common: 0 Bytes (0.00%)

@seaona seaona enabled auto-merge October 16, 2024 10:54
@hjetpoluru hjetpoluru self-requested a review October 16, 2024 12:08
Copy link
Contributor

@hjetpoluru hjetpoluru left a comment

Choose a reason for hiding this comment

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

LGTM

@seaona seaona added this pull request to the merge queue Oct 16, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Oct 16, 2024
@seaona seaona added this pull request to the merge queue Oct 16, 2024
Merged via the queue into develop with commit 71de55b Oct 16, 2024
94 checks passed
@seaona seaona deleted the erc1155-flaky-assert branch October 16, 2024 13:22
@github-actions github-actions bot locked and limited conversation to collaborators Oct 16, 2024
@metamaskbot metamaskbot added the release-12.7.0 Issue or pull request that will be included in release 12.7.0 label Oct 16, 2024
@gauthierpetetin gauthierpetetin added release-12.6.0 Issue or pull request that will be included in release 12.6.0 and removed release-12.7.0 Issue or pull request that will be included in release 12.7.0 labels Oct 21, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-qa Relating to QA work (Quality Assurance) flaky tests release-12.6.0 Issue or pull request that will be included in release 12.6.0 team-extension-platform
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Fix "ERC1155 NFTs testdapp interaction should batch transfers ERC1155 token" flaky test
5 participants