fix(amazonq): XPath Selector for pinContextHelpers and fixing PinContext ability to run in full test suite #7928
Conversation
|
| for (const item of menuListItems) { | ||
| const textWrapper = await item.findElement( | ||
| By.css('.mynah-detailed-list-item-text.mynah-detailed-list-item-text-direction-row') | ||
| await sleep(0) |
There was a problem hiding this comment.
I assume this is needed, but maybe it worth adding a comment about why?
| const item = await waitForElement( | ||
| webview, | ||
| By.xpath( | ||
| `//div[contains(@class, 'mynah-detailed-list-item') and contains(@class, 'mynah-ui-clickable-item')]//div[contains(@class, 'mynah-detailed-list-item-name') and text()='${itemName}']` |
There was a problem hiding this comment.
these strings are gnarly, how does one find this? Are they querying the css based on these attributes?
There was a problem hiding this comment.
Yeah I think they are pretty complex, but I do think this is the best/reliable way to snipe the correct element. Yup, XPath is querying based on the css class attributes. I think in general we can use css selectors, but for this specific instance it may be best to use our XPath. You could find this by using the printElementHTML Function and dumping the entire overlay to figure out what you need if building/debugging a XPath selector.
There was a problem hiding this comment.
Wow cool! Maybe in the future we can build/find a nicer interface on top of these queries? This looks good for now though, nice find!
There was a problem hiding this comment.
Yeah I agree, I think building a helper function for XPaths could be useful, I think it has a lot of moving parameters but definitely doable.
|
/retryBuilds |
| await clickPinContextButton(webviewView) | ||
| await clickPinContextMenuItem(webviewView, 'Files') | ||
| await clickPinContextMenuItem(webviewView, 'Active file') | ||
| await clickSubMenuItem(webviewView, 'Active file') |
There was a problem hiding this comment.
does the File test work properly now? or do we still have to skip it?
4 participants
Problem
We were faced with the problem that when all our tests and helpers were merged together, and then run as a full suite, we saw errors with the pinContext.test.ts file. Namely, it was targeting a background overlay that had identical css components to the pinContext overlay. This is problematic since our entire suite relies on these css components, and even test-ids were not differentiated. Additionally, our pinContextHelpers used sleep functions in the range of 100-3000 ms which is naturally arbitrary values.
Solution
We implement the XPath css selectors that are used within Selenium to identify the pinContext Buttons by text, not css classes or ids. This drastically decreases the length and complexity of our helpers while also eliminating the need for sleep functions other than a sleep(0) function for subMenuItems that is needed for the DOM to be loaded. Below is our success of the tests:
feature/xbranches will not be squash-merged at release time.