michael-s-molina commented on issue #16792:
URL: https://github.com/apache/superset/issues/16792#issuecomment-932401384


   > Top level comment, do we want to summarize a list of Dos and Don'ts like 
Evan did for the emotion guidelines at the top? Not sure if that pattern always 
works
   
   That was my initial thought also but I preferred to add more context to each 
DOs and Don'ts because some are not very clear without the context, e.g. "Do 
not use Cypress". But it's following the Do's and Don't approach:
   Dos:
   - Write simple, standalone tests
   - Avoid nesting when you're testing
   - Keep accessibility in mind when writing your tests
   ...
   
   Don'ts:
   - No warnings!
   - Don't use act unnecessarily
   - Do not use Cypress :)
   ...
   
   > One other comment, if you could link an example test file or two to the 
guidelines (ideally a direct link to the current sha so it never changes) that 
could be helpful. Sometimes showing works better than telling (and honestly, i 
love being able to copy a test file as a template for the new one i'm making)
   
   Great suggestion. Will do.
   
   > Isn't that the opposite as what we recommend for RTL? If it's best 
practices, then I guess it's fine. But maybe we should further call out why we 
have 2 different recommendations?
   
   Wow! Nice catch. I do agree with you. We can query for elements in Cypress 
using accessible attributes like `role`. I was reading the [Cypress Best 
Practices](https://docs.cypress.io/guides/references/best-practices#Selecting-Elements)
 and it seems their main concern is to use selectors that don't change over 
time. So I think we'll be fine following RTL query 
[Priority](https://testing-library.com/docs/queries/about/#priority) and only 
use the `data-test` as a last resort.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to