Cypress E2E Testing Interview Questions India 2026: Selectors, Intercepts, and CI Integration

Cypress has a unique architecture compared to Selenium, which changes how you think about E2E testing.

Cypress vs Selenium:

1. Cypress runs inside the browser (in the same JavaScript execution context as the application); Selenium controls the browser from outside via a WebDriver protocol
2. Benefits of running inside the browser: direct DOM access, no network latency between test runner and browser, ability to stub network calls, automatic waiting
3. No explicit waits: Cypress automatically retries commands until the element is found or the timeout expires; never use cy.wait(2000) for element readiness
4. Commands are asynchronous under the hood but written synchronously — they queue up and execute in order

Core commands:

1. cy.visit('/dashboard') — navigate to a URL (relative to baseUrl in cypress.config.js)
2. cy.get('#submit-btn') — get an element by CSS selector
3. cy.get('[data-testid="login-form"]') — get by data-testid attribute (preferred; resilient to style changes)
4. cy.contains('Submit') — get an element containing the given text
5. cy.get('form').find('input[name="email"]') — find a child element within a parent
6. Chainable: cy.get('ul').children().first().click()

Interactions:

1. .click() — click an element
2. .type('hello@example.com') — type text into an input (clears nothing; use .clear() first if needed)
3. .clear() — clear an input field
4. .check() / .uncheck() — check or uncheck a checkbox or radio button
5. .select('Option Value') — select from a <select> dropdown
6. .trigger('change') — trigger a DOM event
7. .focus() / .blur() — focus or blur an element
8. .scrollIntoView() — scroll an element into the viewport before interacting

Assertions:

1. .should('be.visible') — assert the element is visible
2. .should('have.text', 'Expected text') — assert exact text content
3. .should('contain', 'partial text') — assert partial text
4. .should('have.value', 'input value') — assert input value
5. .should('have.class', 'active') — assert CSS class
6. .should('be.disabled') — assert an element is disabled
7. cy.url().should('include', '/dashboard') — assert the URL contains a path
8. cy.title().should('eq', 'Page Title') — assert the page title

Network interception is one of Cypress's most powerful features and is heavily tested in QA engineer interviews.

cy.intercept for network stubbing:

1. cy.intercept('GET', '/api/users', { fixture: 'users.json' }) — stub a GET request and respond with a fixture file
2. cy.intercept('POST', '/api/login', { statusCode: 200, body: { token: 'test-token' } }) — stub a POST request with an inline response
3. cy.intercept('GET', '/api/data').as('getData') — alias an intercept for waiting: cy.wait('@getData')
4. cy.wait('@getData') — wait for a specific network request to complete before proceeding (better than arbitrary waits)
5. cy.wait('@getData').its('response.statusCode').should('eq', 200) — assert on the network response
6. cy.intercept can also spy (no stubbing): cy.intercept('POST', '/api/submit').as('submitForm') — let the real request through but alias it for assertions
7. Request body assertions: cy.wait('@submitForm').its('request.body').should('deep.equal', { name: 'Alice', age: 30 })
8. Intercept with a route matcher: cy.intercept({ method: 'GET', url: '/api/users/**' }) — use wildcards and patterns

Fixtures:

1. Fixture files are JSON (or other format) files in the cypress/fixtures/ folder
2. Load a fixture: cy.fixture('users.json').then((users) => { / use users data / })
3. Use in intercept: cy.intercept('GET', '/api/users', { fixture: 'users.json' })
4. Fixtures make tests deterministic — the same test data every run regardless of the server state

Custom commands:

1. Add custom commands to cypress/support/commands.ts (or .js)
2. Cypress.Commands.add('login', (email, password) => { cy.visit('/login'); cy.get('[name="email"]').type(email); cy.get('[name="password"]').type(password); cy.get('[type="submit"]').click(); })
3. Call in tests: cy.login('user@example.com', 'password123')
4. Cypress.Commands.add('getByTestId', (id) => cy.get('[data-testid="' + id + '"]')) — shorthand for data-testid selectors
5. Custom commands appear in the Cypress Command Log for easy debugging

Test organisation:

1. describe / context group tests logically; it defines individual specs
2. before() / after() run once per describe block; beforeEach() / afterEach() run before/after each test
3. cy.session() (Cypress 9+): cache and restore session state (cookies, localStorage) across tests to avoid re-logging in for every test

Running Cypress in CI and managing test reliability are key skills for QA engineer and senior frontend engineer roles in India.

CI integration: 1. Headless mode: cypress run (vs cypress open for interactive mode); runs tests without a visible browser window 2. GitHub Actions: use the cypress-io/github-action to install, cache, and run Cypress; it handles browser installation and caching automatically 3. Example GitHub Actions step: - uses: cypress-io/github-action@v6 with: start: npm start wait-on: 'http://localhost:3000' browser: chrome 4. wait-on: the action waits for the app to be ready before running tests 5. Docker: use the cypress/included Docker image for a consistent browser environment in CI

Parallelisation with Cypress Cloud:

1. Cypress Cloud (formerly Cypress Dashboard) orchestrates parallel test runs
2. Add --record --parallel to the cypress run command; tests are distributed across multiple CI machines automatically
3. Cypress Cloud tracks flaky tests across runs and flags them

Artifacts on failure:

1. Cypress automatically captures screenshots on test failure (cypress/screenshots/)
2. Video recording of every run (cypress/videos/) — useful for debugging CI failures
3. Upload artifacts in GitHub Actions: use actions/upload-artifact to preserve screenshots and videos

Best practices and flaky test prevention:

1. Use data-testid attributes for selectors — resilient to CSS class changes and text changes
2. Never use arbitrary waits (cy.wait(2000)); use cy.intercept aliases and cy.wait('@alias') instead
3. Use cy.intercept to stub non-deterministic APIs; tests should not depend on external service availability
4. Avoid testing third-party UIs (payment forms, OAuth windows); stub them at the network level
5. Keep tests independent: each test should set up its own state; do not rely on another test having run first
6. Use cy.session() to cache login state and avoid repeating login in every test
7. Page Object Model (POM): encapsulate page-specific selectors and actions in a class; import and reuse across tests
8. Retry-ability: Cypress retries most commands and assertions automatically; only use .should() for assertions (not .then() with expect()) to get automatic retry behaviour