Cypress and Selenium are both popular automation tools, but they are built differently. Cypress is known for simpler setup and faster feedback in modern web apps, while Selenium is known for broad ecosystem support and flexibility.

Practical Interview Answer

“If the team wants quick setup, strong debugging, and modern web automation in JavaScript, Cypress is a great choice.
If the project needs wider language support and legacy ecosystem compatibility, Selenium remains a strong option.”

Simple Rule

Don’t choose tool by popularity alone. Choose based on application type, team skills, CI needs, and long-term maintenance plan.

In Cypress, good locators are stable, readable, and not affected by UI styling changes.
The best practice is to use dedicated attributes like data-testid or data-cy.

Recommended Locator Priority

1. data-testid / data-cy (most stable)
2. Accessible text/content (when unique and reliable)
3. Semantic attributes like name, placeholder, aria-label
4. Class/id only if stable and not auto-generated

Good vs Bad Examples

// Good (stable)
cy.get('[data-testid="login-button"]').click();
cy.get('[data-cy="email-input"]').type('user@mail.com');

// Okay (if text is unique)
cy.contains('Submit').click();

// Risky (can break if UI changes)
cy.get('.btn.btn-primary.mt-4').click();
cy.get(':nth-child(3) > .row > .col > button').click();

Simple Rule

Choose locators that represent business meaning, not visual structure. If CSS layout changes, your test should still work.

cy.intercept() is used to capture, monitor, and mock network requests in Cypress.
It helps testers validate API calls, control test data, and remove dependency on unstable backend behavior.

Main Use Cases

• Wait for API response before asserting UI.
• Validate request payload and response status.
• Mock API response for edge cases or test isolation.
• Simulate failures like 500 errors or timeout scenarios.

Example 1: Wait for Real API Call

cy.intercept('GET', '/api/orders').as('getOrders');
cy.visit('/orders');
cy.wait('@getOrders').its('response.statusCode').should('eq', 200);
cy.contains('Order List').should('be.visible');

Example 2: Mock API Response

cy.intercept('GET', '/api/profile', {
  statusCode: 200,
  body: { name: 'Test User', role: 'QA' }
}).as('getProfile');

cy.visit('/profile');
cy.wait('@getProfile');
cy.contains('Test User').should('be.visible');

Example 3: Simulate Server Error

cy.intercept('POST', '/api/payment', {
  statusCode: 500,
  body: { message: 'Server error' }
}).as('paymentFail');

cy.get('[data-testid="pay-btn"]').click();
cy.wait('@paymentFail');
cy.contains('Payment failed').should('be.visible');

Why It Is Important in Real Projects

cy.intercept() makes tests more stable and predictable by controlling network behavior.
It is one of the most important commands for reducing flaky tests in Cypress automation.

cy.request() is a Cypress command used to send direct HTTP/API requests without using the UI.
It is very useful for fast setup, backend validation, and test data management.

Where Teams Commonly Use It

• API testing: validate status code, response body, headers.
• Test setup: create users/orders before UI test starts.
• Login shortcut: API-based authentication for faster execution.
• Cleanup: delete test data after execution.
• Health checks: confirm service is up before running UI suite.

Example 1: Simple GET Request

cy.request('GET', '/api/users/101').then((response) => {
  expect(response.status).to.eq(200);
  expect(response.body.id).to.eq(101);
});

Example 2: Create Test Data (POST)

cy.request('POST', '/api/orders', {
  productId: 123,
  quantity: 2
}).then((response) => {
  expect(response.status).to.eq(201);
  cy.wrap(response.body.orderId).as('orderId');
});

Example 3: API Login for Faster UI Tests

cy.request('POST', '/api/login', {
  email: 'qa@test.com',
  password: 'Pass@123'
}).then((response) => {
  window.localStorage.setItem('token', response.body.token);
});

cy.visit('/dashboard');

Why It Is Useful

cy.request() makes tests faster because it avoids slow UI setup steps.
It also improves reliability by validating backend responses directly and clearly.

Most teams avoid full UI login in every test because it is slow and can become flaky.
A common approach is to use API login + session reuse for regular test flows.

Common Team Approach

1. Use API request to authenticate quickly.
2. Store auth token/cookies in local storage or session.
3. Reuse login state across tests.
4. Keep only a few dedicated UI login tests for form validation.

Sample Example (API-based Login)

// cypress/support/commands.js
Cypress.Commands.add('loginByApi', () => {
  cy.request('POST', '/api/login', {
    email: 'testuser@mail.com',
    password: 'Pass@123'
  }).then((resp) => {
    window.localStorage.setItem('authToken', resp.body.token);
  });
});

// in test
beforeEach(() => {
  cy.loginByApi();
  cy.visit('/dashboard');
});

Why Teams Prefer This

• Faster test execution
• Less flakiness from UI timing issues
• Cleaner focus on feature testing

Important Note

Do not skip UI login tests completely. Keep a small set of UI login scenarios to validate
form behavior, error messages, and authentication flow end-to-end.

Running Cypress in CI/CD means executing tests automatically whenever code is pushed or a pull request is created.
This helps teams catch issues early before deployment.

Typical CI/CD Flow

1. Checkout code from repository
2. Install dependencies
3. Run Cypress tests in headless mode
4. Generate reports/screenshots/videos
5. Publish artifacts and mark build pass/fail

Common Commands

npm ci
npx cypress run

Sample GitHub Actions Workflow

name: Cypress Tests

on:
  push:
    branches: [ "main" ]
  pull_request:

jobs:
  cypress-run:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx cypress run
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: cypress-artifacts
          path: |
            cypress/screenshots
            cypress/videos

Best Practices

• Run smoke tests on every PR for fast feedback
• Run full regression nightly
• Store screenshots/videos for failed runs
• Use environment variables for secrets and URLs
• Fail build on critical test failures

Why This Matters

CI/CD integration turns Cypress tests into an automatic quality gate.
It improves release confidence and reduces last-minute production surprises.

A good Cypress framework structure is clean, reusable, and easy for teams to scale.
The goal is to keep tests readable while separating test logic, data, and reusable utilities.

Recommended Folder Structure

cypress/
  e2e/
    smoke/
    regression/
    api/
  fixtures/
    users.json
    products.json
  support/
    commands.js
    e2e.js
    pageObjects/
      loginPage.js
      dashboardPage.js
  utils/
    dataFactory.js
    helpers.js
reports/
cypress.config.js
package.json

Key Design Principles

• Feature-wise test grouping: organize by module/use case.
• Reusable commands: keep common actions in commands.js.
• Data separation: keep test data in fixtures, not hardcoded in test steps.
• Environment-based config: handle QA/UAT/prod-like URLs cleanly.
• Report integration: save logs, screenshots, and CI-friendly results.

Simple Example: Reusable Login Command

// support/commands.js
Cypress.Commands.add('login', (email, password) => {
  cy.get('[data-testid="email"]').type(email);
  cy.get('[data-testid="password"]').type(password);
  cy.get('[data-testid="login-btn"]').click();
});

Why This Structure Works

It reduces duplication, improves readability, and makes onboarding easier for new team members.
Most importantly, it helps maintain test stability as the project grows.

Cypress provides useful logs by default, but most teams add extra reporters for better visibility in CI/CD.
Reports help QA, developers, and managers quickly understand pass/fail trends and failure reasons.

Common Reporting Options

• Default Cypress Reporter: Console output with command logs.
• Mochawesome: HTML-style readable reports with screenshots integration.
• JUnit Reporter: XML reports used by Jenkins, GitLab, Azure DevOps, etc.
• Allure: Rich visual reporting with history and trend dashboards.
• Cypress Cloud Dashboard: Centralized run insights, failure analytics, and parallel run visibility.

Useful Artifacts Teams Usually Store

• Screenshots on failure
• Video recordings of test runs
• Test result XML/JSON files
• Execution logs for debugging

Sample Config (Mochawesome + Screenshots)

// cypress.config.js (example)
module.exports = {
  reporter: 'mochawesome',
  reporterOptions: {
    reportDir: 'cypress/reports',
    overwrite: false,
    html: true,
    json: true
  },
  screenshotOnRunFailure: true,
  video: true
};

How Teams Use Reports in CI

In CI pipelines, teams publish test reports as artifacts after every run.
This makes it easy to check failures without rerunning tests locally and supports release decisions.