This lesson takes a closer, more narrative look at the mistakes most Cypress beginners (and even experienced teams) make, with enough context to understand not just what to avoid, but why.
Why These Mistakes Are So Common
Most Cypress mistakes aren't caused by carelessness, they come from applying mental models from other tools (fixed waits from older Selenium habits) or from reasonable-seeming shortcuts (reusing a styling class as a selector) that only reveal their cost later, as a suite grows.
// A mistake that "works" until the suite grows:
cy.get('.btn-primary').click(); // couples the test to styling, not intent
This passes today. It silently breaks the first time someone renames or removes .btn-primary for purely visual reasons.
Categories of Common Mistakes
1. Selector mistakes (brittle, styling-coupled selectors)
2. Waiting mistakes (fixed delays, missing waits)
3. State mistakes (shared/order-dependent tests)
4. Assertion mistakes (wrong assertion for the actual intent)
Selector mistakes are the most common source of tests breaking during unrelated refactors.
Waiting mistakes are the most common source of both flakiness and unnecessarily slow suites.
State mistakes are the most common source of "passes alone, fails in the full suite" confusion.
Assertion mistakes often let real bugs slip through despite a passing test suite.
Common Mistakes Quick Reference
A scannable summary of this lesson's detailed explanations below.
Passes even when an element is invisible to real users
it.only() left committed
Silently disables other tests in CI
Storing command results in variables
Loses Cypress's async command queue semantics
Overusing { force: true }
Masks real actionability bugs instead of surfacing them
Why These Mistakes' Costs Compound Over Time
A single brittle selector or fixed wait rarely causes a noticeable problem in a five-test suite. The same mistake, repeated across five hundred tests, becomes a serious drag on both CI time and team trust in the suite, since diagnosing which of many similar brittle patterns actually caused a given failure takes real time.
Catching These Mistakes Early, Before They Compound
Code review is the most effective, lowest-cost point to catch these patterns, well before they've been copy-pasted into dozens of other spec files. A short, specific review checklist (mirroring this course's Do's and Don'ts lesson) makes this catchable even for reviewers newer to Cypress.
Flag CSS/styling-based selectors in review, suggesting data-cy alternatives.
Flag any cy.wait(number), asking whether an alias-based or assertion-based wait would work instead.
Flag tests that depend on execution order or another test's side effects.
Common Mistakes
Assuming a passing test suite today means these mistakes aren't present, brittleness often only shows up later.
Fixing an instance of a mistake without addressing the pattern everywhere else it appears in the suite.
Not distinguishing between a deliberate, documented exception and an unnoticed instance of a common mistake.
Waiting for a suite to become painfully slow or flaky before addressing patterns that were visible much earlier.
Key Takeaways
Most common Cypress mistakes stem from reasonable-seeming shortcuts, not carelessness.
Selector, waiting, state, and assertion mistakes are the four broad categories worth watching for.
These mistakes' costs compound significantly as a suite grows past a handful of files.
Code review is the most effective point to catch these patterns before they spread.
Pro Tip
When you catch one instance of a common mistake during review, spend two extra minutes searching the codebase for the same pattern elsewhere, these mistakes are rarely isolated, and catching several instances at once is far more efficient than fixing them one flaky-failure at a time.
You now understand common mistakes in depth. Next, use the consolidated Cypress Cheat Sheet as an ongoing reference.