Cypress测试疑问：.contains()与should('contain')是否等效及元素选择实践

Nice set of questions—let's unpack them one by one!

Are cy.get('[name=planSelect]').contains(dummyPlan) and cy.get('[name=planSelect]').should('contain', dummyPlan) functionally equivalent? #

Short answer: In many common scenarios where you're verifying that the [name=planSelect] element contains the dummyPlan text (either directly or in its child elements), these two lines will behave similarly. But there's a key difference in their intent and behavior:

• cy.get('[name=planSelect]').contains(dummyPlan) is a command that filters elements: It starts with the element matching [name=planSelect], then searches its descendants for elements that contain dummyPlan text, and returns that matching element. It implicitly asserts that such an element exists (it will retry until it finds it or times out).
• cy.get('[name=planSelect]').should('contain', dummyPlan) is an explicit assertion: It verifies that the already-found [name=planSelect] element contains the specified text (checking both the element itself and its descendants). It also retries until the assertion passes or times out.

If your goal is purely to verify that the [name=planSelect] element has the dummyPlan text, they're functionally equivalent. But which should you use?

Recommendation #

If your primary goal is validation, go with .should('contain', dummyPlan)—its intent is crystal clear to anyone reading the test (you're explicitly asserting a condition). The .contains() command is better suited when you need to select an element based on its text to perform further actions (like clicking it). That said, if brevity is your priority and the intent is obvious in context, .contains() works perfectly fine too.

Why does Cypress recommend data-cy attributes over name attributes for element selection? #

Cypress pushes data-cy (or data-test, data-testid) because they solve several pain points that come with using name or other native attributes:

• Better stability: name attributes are tied to business logic (they're used for form submissions, backend data mapping, etc.). It's common for developers to change name values when refactoring forms or updating backend contracts—this breaks tests unnecessarily. data-cy is purely for testing, so it's rarely modified unless the test itself needs to change.
• Clearer semantics: A data-cy="plan-select-dropdown" attribute tells you exactly what the element is for in the context of testing. A name="planSelect" only tells you it's a form field—you have to infer its purpose in the test.
• Avoids ambiguity: Multiple elements on a page can share the same name (e.g., identical form fields in different modals). This forces you to add extra selectors to narrow down the target, making tests more complex. data-cy attributes are designed to be unique per test target, so you can select elements precisely without extra hoops.
• Decouples tests from business code: Your test suite doesn't depend on changes to form field names or other business-focused attributes. This makes tests more resilient to frontend refactors that don't change the user-facing behavior.

内容的提问来源于stack exchange，提问作者redOctober13