-
Notifications
You must be signed in to change notification settings - Fork 5.1k
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
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. |
await transactionItem.isDisplayed(), | ||
true, | ||
`transaction item should be displayed in activity tab`, | ||
); |
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 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`, | ||
); |
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.
anti-pattern
const displayedDescription = await driver.findElement( | ||
'.confirm-approve-content__description', | ||
); | ||
assert.equal(await displayedDescription.getText(), expectedDescription); |
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.
all these above are anti-patterns
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.
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.
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.
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)
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.
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.
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 info, we have this ticket which reflects the work of removing this anti-pattern, and we've been adding some fixes around that:
In parallel, adding this lint rule (if it's possible) could make that no more new tests are using this pattern anymore
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 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); |
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.
anti-patterns
css: '.transaction-list__completed-transactions', | ||
text: 'Approve Token with no spend limit', | ||
}); | ||
assert.equal(await revokeApprovalItem.isDisplayed(), true); |
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.
anti-pattern
|
Builds ready [7a40481]
Page Load Metrics (1969 ± 131 ms)
Bundle size diffs
|
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
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.
Related issues
Fixes: #27896
Manual testing steps
Screenshots/Recordings
Before
After
Pre-merge author checklist
Pre-merge reviewer checklist