Homepage Tests #2591
Homepage Tests #2591
Conversation
test-browser/tests/homepage.js
Outdated
| browser.waitForElementVisible('#side-panel') | ||
| .assert.containsText('#side-panel h6[class^="swapitTitle"]', 'FILE EXPLORERS') | ||
| .waitForElementVisible('#side-panel div[class^="treeview"]') | ||
| .waitForElementVisible('#side-panel ul[key="browser"] > li:nth-child(4)') |
There was a problem hiding this comment.
we had some discussions a while ago about how we should target elements from the e2e tests. The outcome was that we should target with id as much as possible so we don't rely so much in the html structure of the page. Not that you should do this now, but i'd like to open this discussion again
What do you think?
cc @LianaHus
There was a problem hiding this comment.
Yes, using id is the right way to target element as long as id is unique, this is why we prepend a 'location of the element' to the element id. for example "remixHomePageOpenFile'". We still change the UI a lot, and if we use the element type we should change the test each time we change an element type, which will never be the case with id.
There was a problem hiding this comment.
the drawback of this is that with all the tests we'll have, if you have to put an unique id each time for all the tested elements, the html might be spammed.
@ioedeveloper are there some best practices we can refer too?
There was a problem hiding this comment.
Making your browser tests less fragile and more resilient is considered a best practice, and this can be achieved by using a unique identifier (not necessarily an ID due to spamming as stated by @yann300 ). A data-attribute can be used as a better alternative. Here are a few articles to support my claim selecting elements best practices, making-your-ui-tests-resilient-to-change . I'm not so sure how well nightwatch works with data-attributes but it is something i'm willing to look into.
No description provided.