Cypress Interview Questions: Practical QA Answers

A Cypress coding round often fails at a line that looks perfectly reasonable in JavaScript. The candidate stores the result of cy.get(), expects a DOM element immediately, or adds a hard wait when the value is unavailable. That reveals whether they understand Cypress as an enqueued command chain with retryable queries and assertions, rather than a browser-flavored collection of synchronous functions.

Interviewers usually probe that execution model, then move into state control, network behavior, suite design, and failure diagnosis. Examples should show why a choice is reliable, not only that the syntax runs.

Explain the command queue from the failure backward

Consider this incorrect idea:

const price = cy.get("[data-cy=price]").text();
expect(price).to.equal("$19.00");

cy.get() does not return the element for immediate use, and Cypress commands are not ordinary Promises. Commands are queued and run later. Values flow through the chain:

cy.get("[data-cy=price]")
  .should("be.visible")
  .invoke("text")
  .then((price) => {
    expect(price.trim()).to.equal("$19.00");
  });

The query and built-in assertion retry until they pass or time out. Code inside then() runs when the preceding command yields, but then() itself does not make arbitrary application work retryable. If a value changes asynchronously, prefer a retryable assertion on the query:

cy.get("[data-cy=job-status]").should("have.text", "Complete");

A weak answer says Cypress waits automatically. An acceptable answer describes the queue and chaining. A strong answer distinguishes retried queries and assertions from non-query commands, explains why hard sleeps hide state problems, and names the business condition being awaited.

A useful follow-up is “Can you use async and await?” Explain that Cypress commands use their own chain and scheduler, so treating them as native Promises leads to confusing ordering. Plain asynchronous application helpers should be integrated deliberately, not mixed casually into the command queue.

Select elements by meaning and assert business state

Selectors fail when they encode presentation rather than intent. Prefer accessible roles and labels when they express user behavior, or stable data attributes when the product contract needs a dedicated test hook. Deep CSS chains and positional selectors couple tests to markup.

This test states both action and outcome:

cy.get("[data-cy=cart-count]").should("have.text", "0");
cy.contains("button", "Add to cart").click();
cy.get("[data-cy=cart-count]").should("have.text", "1");
cy.contains("[role=alert]", "Added to cart").should("be.visible");

If there are multiple products, scope the action within the correct card rather than assuming the first button. Ask the team to expose a product identifier when visible text is localized or mutable.

Auto-retry is not a substitute for a precise oracle. “Element exists” may pass before the page is usable. Verify the state that matters: calculated total, saved record, navigation, enabled action, or accessible message. Conversely, asserting every CSS class makes refactoring expensive without increasing confidence.

When asked about timeout changes, diagnose first. A local timeout can represent an intentionally long operation. A global increase often makes every real failure slower and conceals an unobserved dependency. Wait for a network alias or a visible state with a justified bound.

Use network control without erasing integration risk

cy.intercept() can observe real traffic or provide a stubbed response. The choice should follow the test's purpose. This example verifies how the UI handles an unavailable recommendations service:

cy.intercept("GET", "/api/recommendations*", {
  statusCode: 503,
  body: { code: "RECOMMENDATIONS_UNAVAILABLE" },
  delay: 150
}).as("recommendations");

cy.visit("/products/A17");
cy.wait("@recommendations")
  .its("request.url")
  .should("include", "productId=A17");

cy.contains("Recommendations are temporarily unavailable")
  .should("be.visible");
cy.get("[data-cy=product-details]").should("be.visible");

The test proves graceful frontend behavior deterministically. It does not prove the deployed recommendations service, gateway, authentication, or real response contract. Keep a smaller integrated path or API contract coverage for that risk.

For a successful write, inspect request and response selectively:

cy.intercept("POST", "/api/orders").as("createOrder");
cy.get("[data-cy=submit-order]").click();

cy.wait("@createOrder").then(({ request, response }) => {
  expect(request.body.items).to.have.length.greaterThan(0);
  expect(response.statusCode).to.equal(201);
  expect(response.body.id).to.match(/^ord_/);
});

Do not use cy.wait("@alias") merely as a timer. Connect the request to a meaningful UI assertion. Also register the intercept before the action that triggers traffic, or a fast request can escape observation.

An advanced probe asks whether a route should be mocked for every end-to-end test. The answer is no. Stubs improve control over rare states and frontend isolation, but excessive stubbing creates a parallel reality that can drift from production.

Isolate tests through state and data ownership

Order-dependent tests are a design defect. Each test should create or select known state and leave shared environments safe. Visiting a page after another test happened to log in or create data makes local success misleading.

Use programmatic setup where it is a public, supported shortcut. cy.request() can create a record or establish a session faster than repeating UI setup. cy.session() can cache validated login setup, but the validation must prove the cached state remains usable. Do not cache a single account that parallel jobs mutate unpredictably.

A practical strategy is:

• Generate a run-specific namespace for mutable records.
• Create valid state through an API or controlled task.
• Use the UI for the behavior under test.
• Clean up when data volume or privacy requires it.
• Keep one separate path that validates login or setup through the UI.

Fixtures are static data files, not automatically realistic test data. They work well for stable stubs and clear examples. Builders are better when cases need small variations. Secrets and environment-specific credentials do not belong in fixtures committed to the repository.

If an interviewer asks whether beforeEach() is bad, discuss scope. Shared navigation and fresh setup can clarify tests. A large hook that silently creates many entities and aliases makes failures difficult to trace. Optimize for readable prerequisites, not the fewest lines.

Place component and end-to-end checks deliberately

Cypress component testing can mount a UI component with controlled props and dependencies. It is valuable for state-rich widgets, error displays, accessibility behavior, and combinations that are expensive to reach through the full application.

Imagine a file uploader with idle, uploading, failed, retrying, and complete states. Component tests can cover rendering and actions quickly with controlled responses. An end-to-end test should still prove that a real file travels through routing, storage, and permissions.

When choosing a layer, ask where the risk originates:

A strong framework discussion does not put every check in Cypress because Cypress is available. It minimizes feedback time and maintenance while protecting important integration boundaries.

Design abstractions that keep intent visible

Custom commands are useful for Cypress-specific interactions used across tests, such as authenticated session setup. They are less useful as a dumping ground for every page action. A command called cy.completeEverything() hides sequence, data, and failure location.

Page objects can work, but avoid returning Cypress subjects as though they were synchronous values. Keep methods small and express behavior in the test. Functional helpers or focused “app actions” may fit JavaScript better than large class hierarchies.

Compare these interfaces:

checkoutPage.placeOrder();

placeOrder({
  customer: customer.id,
  item: { sku: "A17", quantity: 2 },
  delivery: "standard"
});
cy.get("[data-cy=order-confirmation]")
  .should("contain.text", "Order confirmed");

The second exposes the business inputs and keeps the assertion near the scenario. The helper can still encapsulate stable mechanics.

Framework answers should cover configuration boundaries, TypeScript types if used, linting, data builders, network helpers, reporting, CI splitting, and ownership. They should also explain what will not be abstracted until duplication or volatility justifies it.

Diagnose flake with artifacts, not retries alone

When a test fails only in CI, classify it before changing code. Common classes include unstable selectors, unobserved application state, data collision, test order, animation, network variance, resource pressure, clock dependence, and environment defects.

Capture the command log, screenshot or video where configured, browser console, request aliases, test attempt, seed, and CI machine context. Compare a passing and failing run. If clicking occurs before an overlay disappears, assert the overlay state. If parallel tests share an account, isolate data. If the backend response is slow, observe the request or user-visible completion rather than sleeping.

Retries can measure and contain rare infrastructure noise while the cause is investigated. They should not convert the first failed attempt into invisible success. Track first-attempt failures, because a suite that passes on retry may still provide late and untrustworthy feedback.

A useful project story states the false lead and evidence. For example, the team first increased a timeout, but screenshots showed the wrong duplicate-named button was clicked after a responsive layout change. The durable fix was scoped selection and a stable product identifier, followed by removal of the larger timeout.

Show judgment in a Cypress exercise

In a live task, narrate the state you need, the behavior under test, and the observable result. Add one meaningful negative path rather than many shallow assertions. If the app is unavailable, explain which boundary you would stub and what integration confidence remains missing.

Use this calibration:

Prepare to repair a flaky snippet, design a cy.intercept() scenario, and explain when cy.request() is appropriate. Also bring one real suite decision: perhaps moving validation combinations to component tests shortened feedback while retaining two integrated purchase journeys. Explain the risk analysis and how you verified the change did not remove necessary coverage.

The interview is not won by knowing the largest number of Cypress commands. It is won by showing that the commands produce repeatable evidence about a product, and that when the evidence fails, your design helps the team discover why.