search

cypress-io / cypress-documentation

Cypress Documentation for the Cypress App, API, Cypress Cloud, UI Coverage and Cypress Accessibility.
https://docs.cypress.io
MIT License
952 stars 1.05k forks source link

Reword Element Selector Best Practices to Better Support Projects with Strict Guidelines #3218

Closed phobetron closed 6 months ago

phobetron commented 4 years ago

Our codebase relies heavily on having strictly-defined markup for adherence to semantics, accessibility standards, and BEM-style naming conventions. In our E2E tests, if something significant changes in the markup, we want tests to break. What may be called "brittle" in some contexts is a protective feature in ours.

Not everyone can detect the nuance in the document, that it intends to protect users who have loosely-defined markup with classes tied to styling, dynamic IDs, and other attributes that may change often. For those who don't understand the context, they see the red and yellow warning signals, the big green Best Practice statement, and become apprehensive to stray from their perceived word of the authority.

Ridiculously, what usually happens is developers add a data attribute that perfectly duplicates each element's BEM class name. Any discussion eventually devolves to "but Cypress said to always use data attributes, and everything else is a dirty anti-pattern!"

What I would like to see is some wording and/or some positive example that better points out that "sparingly" or "depends" may be perfectly valid under some circumstances. Vue.js has done something like this with its best practice documentation for scoped styles, stating that using the scoped attribute is just one valid method of adding scope to styles. That definitely helped me maintain my sanity in that discussion.

jennifer-shehane commented 4 years ago

Yes, you should always do what's best for your project's needs over our best practices. The recommendation is helpful in most circumstances. We'd be open to a PR to clarify this messaging.