test: [POM] Migrate token tests #29375
Conversation
…tamask-extension into qq-mulitple-tokens-migration
…tamask-extension into qq-mulitple-tokens-migration
…-send-ecr20-to-contract
…-send-ecr20-to-contract
|
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. |
| private readonly swapButton = { | ||
| text: 'Swap', | ||
| css: '.icon-button', | ||
| }; |
There was a problem hiding this comment.
Using text based selectors here, it's more accessible and means we don't have to create multiple selectors depending on the type of token screen we are looking at. i.e Is the token enabled for swap, bridge, send etc.
The other selector would be either coin-overview-* or token-overview-* or eth-overview-*
This would cause flakiness in the e2e test. I do think there is a bug on the correct selector/element being rendered. It is not affecting the user but they might need to cover it with unit tests so something else does not break
Builds ready [7f54477]
Page Load Metrics (1801 ± 78 ms)
Bundle size diffs
|
| const percentageElement = await this.driver.findElement( | ||
| this.tokenPercentage(assetAddress), | ||
| ); | ||
| const percentage = await percentageElement.getText(); |
There was a problem hiding this comment.
mmm this is an anti-pattern that opens the door to race conditions, where the element is rendered but it does not have yet the value we expect.
We should try to avoid finding an element and then getting its text where possible. I think in this case it's possible to avoid this. In the specs below, we should directly try to find the element by its expected inner value instead of this assert
const percentage =
await assetListPage.getAssetPercentageIncreaseDecrease(tokenAddress);
assert.equal(percentage, '');
What do you think?
There was a problem hiding this comment.
Good point! I agree with you here. I have used isElementPresent to check for the existence of the element for a given token address
|
|
||
| private readonly swapButton = { | ||
| text: 'Swap', | ||
| css: '.icon-button', |
There was a problem hiding this comment.
A couple of small things:
- could we sort these selectors alphabetically maybe?
- I think these buttons are the exact same buttons we have in the home screen. Maybe we could separate them in their own component, and re-use them in the homepage class and in the token overview class? Just a thought, it doesn't have to be in this PR. The advantage would be that if a button from this group changes, we'll only need to update it in one place. The disadvantage might be that it might complicate a bit the component? though not too much. What are your thoughts? In any case, it can be left outside this PR, if we decide to have this separate component
There was a problem hiding this comment.
Yes, I also had the same thought. It could make sense (if we keep it text based as I have done here)
the only doubt that I have is the depending on the token type different buttons are displayed so that is still something to think about. I do agree though there is a way we could make this easier to deal with
| await driver.findElement(`[data-testid="${testId}"]`) | ||
| ).getText(); | ||
| const percentage = | ||
| await assetListPage.getAssetPercentageIncreaseDecrease(tokenAddress); | ||
| assert.equal(percentage, ''); |
There was a problem hiding this comment.
with these 2 asserts race conditions can happen (see above comment)
…tension into qq-more-token-tests
…-more-token-tests
Builds ready [6be682d]
Page Load Metrics (1758 ± 61 ms)
Bundle size diffs
|
Builds ready [c09fd7d]
Page Load Metrics (1613 ± 47 ms)
Bundle size diffs
|
Description
asset-listPage Object - Adds methods for interacting with token list (i.e sorting, getting list, assertion on increase/decrease price and percentage)send-tokenpage for warning messagetoken-overviewimport-tokens,send-erc20-to-contract,token-listandtoken-sortRelated issues
Fixes:
Manual testing steps
Screenshots/Recordings
Before
After
Pre-merge author checklist
Pre-merge reviewer checklist