You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
our philosophy aligns closely with Testing Library's ethos and approach to writing tests. We strongly endorse their best practices.
I feel that the current guidance to suggest using data- testing attributes is bad and diminishes the value of tests by disregarding semantic HTML. See the link to RTL for more reasons. If a user is clicking a link, it should be an a tag (not a button or anything else), and the test should enforce that.
In the table of example selectors, one of the best options is cy.get('button').contains('Submit').click(), but this example is missing from the table.
The strategy to take here also depends on how much control/ownership a team has over the UI they are testing against. Some teams can afford to be looser or tighter with the selectivity depending on their organizational structure. Another factor to consider is what types of unit/integration tests are supporting their cypress e2e tests. I was disappointed to see the approach recommended without providing this context, and I think this section should be revised. I would offer to lend a hand, but it is an opinionated guide that needs to be authored by a core contributor IMO.
The text was updated successfully, but these errors were encountered:
Subject
guides
Description
The Selecting Elements section in Best Practices contradicts the react testing library guide
even though the same doc claims says
I feel that the current guidance to suggest using
data-
testing attributes is bad and diminishes the value of tests by disregarding semantic HTML. See the link to RTL for more reasons. If a user is clicking a link, it should be ana
tag (not abutton
or anything else), and the test should enforce that.In the table of example selectors, one of the best options is
cy.get('button').contains('Submit').click()
, but this example is missing from the table.The strategy to take here also depends on how much control/ownership a team has over the UI they are testing against. Some teams can afford to be looser or tighter with the selectivity depending on their organizational structure. Another factor to consider is what types of unit/integration tests are supporting their cypress e2e tests. I was disappointed to see the approach recommended without providing this context, and I think this section should be revised. I would offer to lend a hand, but it is an opinionated guide that needs to be authored by a core contributor IMO.
The text was updated successfully, but these errors were encountered: