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.

Bridging the Gap: Practical Phrasing for Cypress Teams

For non-native English speakers tackling Cypress testing, it’s not just about knowing the commands – cy.get(), cy.click(), etc. It’s about communicating effectively within a development team that relies heavily on precise language and collaborative feedback loops. Often, misunderstandings arise simply because of subtle differences in how concepts are expressed. Let’s look at some common scenarios where using the right phrasing can dramatically improve your workflow and ensure everyone’s on the same page.

One frequent situation is during code reviews. Receiving a comment like “This test isn’t robust enough” can be frustrating without context. Instead of just accepting it, try to elicit more information. A better approach would be: “Could you elaborate on what specifically makes this test less robust? Are there specific scenarios we haven’t covered, or is the assertion failing under certain conditions?” Similarly, a PR description should clearly articulate why you’re making changes. Saying “Fixed bug” isn’t enough; explain the problem, the solution, and how it was verified – “Implemented a retry mechanism to handle intermittent network issues that were causing the form submission to fail. Verified this fix by simulating a slow connection using cy.request() and confirming successful data transmission.” This level of detail demonstrates understanding and reduces ambiguity for your reviewers. Furthermore, when discussing flaky tests (those that intermittently pass or fail), avoid vague terms like “it’s broken.” Instead, use phrases like “This test exhibits inconsistent behavior” or “We need to investigate the root cause of this intermittent failure.”

Another area where precise language matters is in Slack conversations. Imagine a discussion about a failing test: “It’s just not working!” That doesn’t provide any actionable information. A more productive response would be, “The cy.get() command isn’t consistently locating the element. I suspect there might be issues with CSS selectors or changes to the UI impacting its visibility.” Sharing your observations – even if they seem obvious – helps others understand the problem and potentially identify a solution faster. Remember, concise and specific language is key for efficient collaboration.

Finally, consider how you frame test triage discussions. Instead of simply saying “This test is flaky,” detail how it’s flaky: “The test fails approximately 10% of the time, primarily when loading the page under high network latency. We’ve identified a potential race condition with asynchronous data fetching which we need to address.” This provides valuable context for prioritization and debugging efforts.

cy.task('slow_network', {duration: 5000}) // Simulate slow network conditions for testing

This command, using cy.task(), demonstrates how a specific technical action is often described – not just as “testing network issues,” but as deliberately creating a scenario to observe behavior. It’s about communicating the intent and the methodology.