Cypress interview questions

Architecture and commands

1. What is Cypress?

Cypress is a JavaScript-based testing tool for browser applications, with end-to-end and component testing modes. It combines a runner, commands and assertions. Use it to check a checkout workflow, while testing business calculations at a lower layer where possible.

2. How does its architecture differ from Selenium?

Cypress executes test logic in the browser with a supporting Node process and network proxy. Selenium WebDriver sends automation commands through browser drivers. This difference affects integration and browser control; it does not prove that one tool catches more bugs.

3. Can you use Java to write Cypress tests?

Cypress tests use JavaScript or TypeScript, not Java test classes. A Java backend does not prevent a team from testing its web interface with Cypress. The choice depends on the testing team’s skills and required browser workflows, not only the backend language.

4. Are Cypress commands ordinary synchronous function calls?

No. Commands are enqueued and execute later in order. A variable assigned from a command is not immediately the element or response. Read yielded values in a command callback and avoid interleaving assumptions about synchronous state.

5. What does a command chain yield?

Each command passes a subject to the next appropriate command. A DOM query can yield matched elements, while a request yields a response. Read the command’s contract rather than assuming every chain continues to carry the original element.

6. Why should you avoid async and await around Cypress commands?

Cypress commands are queued chainables rather than ordinary promises for a test to await. Mixing the two execution models can introduce ordering mistakes. Use the command queue and its callbacks, and isolate genuinely external async work deliberately.

7. What is a reliable locator strategy?

Prefer stable test attributes or suitable accessible queries over selectors tied to layout. ShopLite exposes data-testid attributes for this purpose. A locator should also identify the intended user control, rather than matching every button and selecting one by incidental index.

8. What does should do?

It attaches an assertion, and linked queries can retry until that assertion passes or times out. Keep assertion callbacks free of side effects that would be unsafe to repeat. Repeatedly submitting an order inside an assertion is very different from checking its displayed status.

Retry-ability and isolation

9. How does query retry-ability work?

Linked queries and assertions retry together to observe the expected state. Action commands execute once after relevant waiting, rather than replaying arbitrary user actions until a result appears. This distinction prevents duplicate checkout submissions from being treated as an ordinary waiting strategy.

10. How is then different from should?

A then callback is not retried like a should assertion callback. Use it to inspect or transform a yielded value when that is the intended behavior. If a DOM state must eventually change, put the expectation in a retrying assertion rather than reading it once too early.

11. Why avoid a fixed sleep?

A fixed delay guesses when a condition will become true and wastes time when it is already true. Wait for an observable UI state or an aliased network call. A response finishing still does not prove the UI rendered the correct outcome, so follow it with a UI assertion.

12. How do command retries differ from test retries?

Query retries wait within a command chain; test retries rerun a failing test attempt according to runner configuration. A later successful attempt can hide shared state or an intermittent product failure. Retain evidence from failed attempts and investigate the cause.

13. What does test isolation provide?

With end-to-end isolation enabled, Cypress resets browser context between tests, including cookies and storage. It does not reset your backend database. Two tests using the same server-side cart can interfere even when their browser state is clean.

14. How do you avoid stale element problems?

Query the current DOM after actions that can trigger rerenders instead of retaining a detached node. Waiting for an app-ready condition also matters. A typing example failed during local verification and was omitted; its cause was not established. The custom command example below checks a control’s visibility and attributes without making a claim about typing.

15. What belongs in beforeEach?

Set up only the state each test needs, such as visiting a known page or creating isolated test data. Keep tests runnable independently. One test should not be responsible for logging in or creating the order that a later test assumes already exists.

16. Should you increase every timeout to fix flakiness?

First determine whether the app is slow, the locator is wrong, the request failed or data is shared. A targeted timeout can be justified for a known slow operation. A global increase often makes genuine failures slower without making the evidence more reliable.

Network, fixtures and reuse

17. What does intercept do?

It can observe, modify or stub matching application network traffic. Register it before the action that starts the request. A stubbed response tests behavior under the supplied data, not whether the real backend implements that behavior.

18. Why alias an intercepted request?

An alias lets the test wait for a matching request and inspect its interception details. Match method and URL narrowly enough to avoid waiting for an unrelated call. A request alias is not a replacement for asserting what the user sees.

19. Why might a network assertion see 304 instead of 200?

Conditional requests can receive a 304 response when the server validates a cached representation. That occurred in this page’s first verification run. The example removes the if-none-match header from the intercepted request to require a fresh representation; it does not claim the original 304 was a product defect.

20. What are fixtures useful for?

They hold deterministic non-secret test inputs or stubbed responses. Use a deliberately empty product response to check the empty-state UI. Keep fixtures aligned with the current contract; a beautifully passing UI test can still rely on obsolete fake data.

21. When is a custom command appropriate?

Use it for repeated domain actions or locator conventions with a clear contract. The byTestId command below wraps a simple query. Do not hide a whole unrelated business workflow behind one command that makes failures hard to locate.

22. How can you test an API directly?

The request command sends HTTP requests and yields a response for assertions. That is useful for setup or direct contract checks. An intercept of the application’s browser requests does not automatically spy on these direct request commands.

23. What does component testing cover?

It mounts a component in a real browser with the configured framework tooling and checks interactions in isolation. A cart summary can be tested without deploying the whole application. Routing, services, styles and providers still need appropriate setup, and full journeys need separate coverage.

24. Where should Node-only work go?

Use the Node-side task mechanism for approved filesystem or database work that cannot run in the browser. Define explicit tasks and return serializable results. Keep secrets and privileged operations out of browser test code and never expose arbitrary command execution to untrusted input.

Practical example and decisions

25. What does a complete small ShopLite spec look like?

The following spec exercises a real catalogue, an intercept, a custom command, an empty-state fixture and a direct API response. The fixture and configuration follow in the next answer. It checks selected behavior in the deliberately buggy app; five green examples do not mean the app has no defects.

Cypress.Commands.add('byTestId', (id) => cy.get(`[data-testid="${id}"]`));
describe('ShopLite examples', () => {
  it('opens the catalogue', () => {
    cy.visit('/#/products');
    cy.get('[data-testid="search"]').should('be.visible');
    cy.get('[data-testid="product-card"]').should('have.length.greaterThan', 0);
  });
  it('waits for the catalogue request', () => {
    cy.intercept('GET', '**/api/products*', (req) => {
      delete req.headers['if-none-match'];
    }).as('products');
    cy.visit('/#/products');
    cy.wait('@products').its('response.statusCode').should('eq', 200);
    cy.get('[data-testid="product-card"]').should('exist');
  });
  it('uses a custom command', () => {
    cy.visit('/#/products');
    cy.byTestId('product-card').should('exist');
    cy.byTestId('search').should('be.visible').and('have.attr', 'type', 'search');
  });
  it('stubs an empty catalogue', () => {
    cy.intercept('GET', '**/api/products*', { fixture: 'empty-products.json' }).as('empty');
    cy.visit('/#/products');
    cy.wait('@empty');
    cy.get('[data-testid="no-products"]').should('contain.text', 'No products found');
  });
  it('checks the real API', () => {
    cy.request('/api/products').then((response) => {
      expect(response.status).to.eq(200);
      expect(response.body.items).to.be.an('array').and.not.be.empty;
    });
  });
});

26. What configuration and fixture does that spec need?

Save the configuration as cypress.config.cjs, the spec as cypress/e2e/shoplite.cy.js, and the JSON as cypress/fixtures/empty-products.json in a scratch Cypress project. Support-file loading is disabled because the custom command is declared directly in the spec. These exact files were used in the local verification.

const { defineConfig } = require('cypress');
module.exports = defineConfig({
  e2e: { baseUrl: 'http://localhost:3001', supportFile: false },
});

{"items":[],"total":0,"page":1,"pages":0}

27. How do you run this spec in CI?

Start ShopLite first and wait for its HTTP endpoint to respond, then invoke the runner from the configured Cypress project. This command was run locally in Chrome; no hosted CI workflow was executed. Preserve the runner exit code and retain failure artifacts.

npx cypress run --browser chrome --spec cypress/e2e/shoplite.cy.js

28. Can Cypress test multiple tabs and origins like Playwright?

Cypress’s built-in model does not provide the same general multi-page control as Playwright browser contexts. Cross-origin flows have a dedicated origin mechanism with restrictions. Prototype the actual payment redirect or popup requirement rather than assuming all browser workflows transfer unchanged.

29. What are the limitations compared with Selenium?

Cypress does not use Selenium Grid’s WebDriver model and does not provide Selenium’s range of client languages. Browser and native-device requirements need separate evaluation; browser viewport emulation is not native mobile testing. Verify current supported browsers instead of claiming Cypress runs every browser or real Safari.

30. How would you decide whether to adopt Cypress?

Try representative flows, including authentication, redirects, downloads, test data and failure diagnosis. Judge maintenance effort and evidence quality for your team. Do not replace a working suite solely because a demonstration has fewer lines.

Likely follow-up: What did you actually run? Name the browser, runner version, tested flows and remaining gaps rather than saying the whole framework was verified.

Practise it

Run the examples against ShopLite, then add one assertion for a planted defect. Explain whether the new test uses the real backend or a stub, and what each result establishes.