English for Cypress Testing

End-to-end testing with Cypress has its own vocabulary for describing how tests interact with a running application — “command,” “intercept,” and “flake” all carry specific technical meaning. Teams that describe every failing test as “flaky” without further detail waste time re-running tests instead of fixing root causes. This guide covers the terms for discussing Cypress tests precisely.

Key Vocabulary

Command — a chainable Cypress API call (cy.get, cy.click, cy.type) that queues an action or assertion to run against the application under test. “Chain a cy.get command with a should assertion instead of a manual wait — Cypress automatically retries until the element appears.”

Fixture — a static file (usually JSON) containing mock data, loaded into a test to stub a predictable API response. “We’re loading the fixture for an empty cart state so we can test the empty-state UI without depending on a real backend.”

Intercept — a Cypress command (cy.intercept) that stubs or spies on network requests, letting tests control API responses or wait for a request to complete. “We added an intercept on the checkout endpoint so the test waits for the actual network call to resolve before asserting on the confirmation page.”

Flaky test — a test that passes and fails inconsistently across runs without any change to the code, usually caused by timing issues, unhandled async behavior, or test pollution. “This isn’t a flaky test in the vague sense — it’s failing specifically when the API response takes longer than the hardcoded animation duration.”

Test isolation — the practice of ensuring each test starts from a clean, independent state, so one test’s actions don’t affect another’s outcome. “We lost test isolation when we started sharing a single seeded user across tests — now failures in one test cascade into unrelated ones.”

Custom command — a reusable Cypress command defined in cypress/support/commands.js, used to encapsulate repeated multi-step actions like logging in. “Instead of repeating the five-step login flow in every test, we wrapped it in a custom command called cy.login.”

Common Phrases

• “Is this actually flaky, or is it failing consistently under a specific condition?”
• “Did we intercept this request, or is the test hitting a real backend?”
• “Let’s check test isolation — is this failure caused by state left over from a previous test?”
• “Should this be a custom command? We’re repeating this same sequence in four other tests.”
• “Is the fixture still in sync with the actual API response shape?”

Example Sentences

Reporting a test failure precisely: “This test only fails in CI, not locally, and only when it runs after the checkout suite — that points to leftover state from a previous test, not a genuine flaky timing issue.”

Explaining a testing strategy in a design review: “We’re intercepting the payment API in this suite so tests don’t depend on a real payment gateway, but we’ve kept one true end-to-end test that hits the real staging environment for the critical checkout path.”

Discussing test maintenance with a teammate: “Let’s extract the repeated login and cart-setup steps into custom commands — right now every new test copies fifteen lines of setup, and any change to the login flow means updating them all.”

Professional Tips

• Avoid saying “flaky” as a catch-all — specify whether the failure is timing-related, state-related, or environment-specific, since each has a different fix.
• Say “intercept” specifically when a test stubs network traffic, distinguishing it clearly from tests that hit a real backend, which behave differently under load.
• Emphasize test isolation when reviewing new test suites — shared state between tests is one of the most common sources of intermittent failures.
• Use “custom command” when suggesting a refactor to reduce duplication, since it’s the idiomatic Cypress pattern reviewers will recognize immediately.

Practice Exercise

1. Explain in two sentences the difference between a genuinely flaky test and one that fails due to lost test isolation.
2. Write a one-sentence bug report describing a test that depends on a real backend instead of an intercept.
3. Describe, in your own words, when you’d extract a sequence of commands into a custom command.