Cypress Do's and Don'ts

Sometimes the clearest way to internalize best practices is a direct do/don't comparison. This lesson presents the most important Cypress recommendations in that format.

Do vs. Don't, Side by Side

Each recommendation below pairs a common anti-pattern with its preferred alternative, making the contrast, and the reasoning behind it, as concrete as possible.

// Don't
cy.wait(2000);

// Do
cy.get('[data-cy="results"]').should('have.length.greaterThan', 0);

The "do" version waits exactly as long as needed and expresses what is actually being waited for.

The Format of Each Entry

Don't: <anti-pattern, with brief reasoning>
Do: <preferred alternative, with brief reasoning>

Each entry targets a specific, common decision point in writing Cypress tests.
The "don't" side is a genuinely common pattern, not a strawman, most teams start with several of these.
The "do" side reflects the reasoning already covered in depth earlier in this course.

Do's and Don'ts Quick Reference

The most impactful pairs, condensed into one scannable table.

Don't	Do
`cy.get('.css-1a2b3c')`	`cy.get('[data-cy="submit"]')`
`cy.wait(2000)`	`cy.wait('@alias')` or an assertion-based wait
Store a command's result in a plain variable	Use `.then()` or an alias (`.as()`)
Log in via the UI in every test	`cy.session()` + API login
Leave `it.only()` committed	Remove `.only()`/`.skip()` before committing
Share state/order dependence between tests	Reset state in `beforeEach()`
Hit a real backend for every test	Stub with `cy.intercept()` for most feature tests

More Do's and Don'ts Worth Internalizing

Don't	Do
Assert `exist` when you mean visible	Use `be.visible` for real user-facing visibility checks
Force clicks by default	Investigate why an element isn't actionable first
Write one giant spec file per feature	Split by scenario, keep files focused and readable
Overwrite built-in commands casually	Reserve overwriting for genuinely cross-cutting concerns
Disable retries/timeouts globally to "fix" flakiness	Diagnose and fix the actual root cause

Why the Do/Don't Format Helps in Practice

During code review, referencing a specific "don't" pattern by name is faster and clearer than re-explaining the underlying reasoning every time, while still pointing reviewers back to this reference for the full context when needed.

Common Mistakes

Treating a "don't" as an absolute rule with zero legitimate exceptions, rather than a strong default.
Applying these guidelines to new code while leaving existing violations completely unaddressed.
Using this list as a substitute for understanding the reasoning behind each recommendation.
Not adapting the list to project-specific nuances that may justify a documented exception.

Key Takeaways

Most Cypress anti-patterns have a clear, well-established preferred alternative.
This do/don't format is useful shorthand during code review and onboarding.
Treat these as strong defaults, not absolute rules with zero exceptions.
The reasoning behind each entry is covered in depth in earlier lessons in this course.

Pro Tip

Pin this do/don't table somewhere visible to your team, a shared wiki page, a PR template comment, or a linked reference in your contributing guide, visibility during actual code review matters more than a one-time read-through ever will.