Why Cypress is built for modern web testing - Framework Benefits

Framework Mode - Why Cypress is built for modern web testing

Folder Structure

cypress-project/
├── cypress/
│   ├── e2e/               # Test files (end-to-end tests)
│   │   └── example.cy.js
│   ├── fixtures/          # Static test data (JSON files)
│   │   └── user.json
│   ├── support/           # Custom commands and reusable code
│   │   ├── commands.js
│   │   └── e2e.js
├── cypress.config.js      # Main Cypress configuration file
├── package.json           # Project dependencies and scripts
└── README.md              # Project overview and instructions

Test Framework Layers

• Test Layer (cypress/e2e): Contains the actual test scripts that simulate user actions and verify app behavior.
• Support Layer (cypress/support): Holds reusable commands, custom helpers, and global setup for tests.
• Fixtures Layer (cypress/fixtures): Stores static data files used to feed tests with consistent inputs.
• Configuration Layer (cypress.config.js): Defines environment settings, browser options, base URLs, and test timeouts.

Configuration Patterns

Cypress uses a single cypress.config.js file to manage settings. It supports:

• Environment Variables: Define different URLs, credentials, or flags for dev, staging, and production.
• Browser Selection: Easily switch between Chrome, Firefox, Edge, or Electron for tests.
• Test Timeouts and Retries: Configure how long Cypress waits for elements and how many times to retry failed tests.
• Base URL: Set a common URL prefix to simplify test code.

Example snippet from cypress.config.js:

import { defineConfig } from 'cypress'

export default defineConfig({
  e2e: {
    baseUrl: 'https://example.com',
    env: {
      username: 'testuser',
      password: 'password123'
    },
    retries: 2
  }
})

Test Reporting and CI/CD Integration

Cypress provides built-in test reporting with clear pass/fail results in the Test Runner UI. For CI/CD pipelines, it supports:

• JSON and JUnit Reports: Export test results for integration with Jenkins, GitHub Actions, GitLab, etc.
• Dashboard Service: Optional Cypress Dashboard offers advanced analytics, flake detection, and parallel test runs.
• Headless Mode: Run tests without UI in CI environments using cypress run.

Example GitHub Actions snippet to run Cypress tests:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: cypress-io/github-action@v5
        with:
          browser: chrome
          headless: true

Framework Design Principles

• Automatic Waiting: Cypress waits for elements and commands automatically, reducing flaky tests.
• Real Browser Execution: Tests run inside the browser, giving accurate results like a real user experience.
• Time Travel Debugging: Cypress records snapshots during test runs to help debug failures easily.
• Easy Setup and Configuration: Minimal setup with zero extra drivers or servers needed.
• Modular Support Layer: Use support/commands.js to keep reusable code clean and maintainable.

Self Check

Where in this folder structure would you add a new custom command to log in users for multiple tests?

Answer: Add it inside cypress/support/commands.js to keep reusable commands centralized.

Key Result

Cypress is built for modern web testing by running tests inside real browsers with automatic waits and easy configuration.

Practice

1. What is one main reason Cypress is built specifically for modern web testing?

easy

A. It uses outdated browser automation techniques.

B. It requires manual test execution only.

C. It only supports testing on mobile devices.

D. It runs tests directly in the browser alongside the app.

Solution

1. Step 1: Understand Cypress test execution

   Cypress runs tests inside the browser where the app runs, allowing real-time interaction and faster feedback.

2. Step 2: Compare options with Cypress design

   Options A, B, and C contradict Cypress's modern approach. It supports desktop browsers, runs tests automatically, and uses modern automation.

3. Final Answer:

   It runs tests directly in the browser alongside the app. -> Option D

4. Quick Check:

   Runs tests in browser = D [OK]

Hint: Remember Cypress runs tests inside the browser itself [OK]

Common Mistakes:

• Thinking Cypress only works on mobile
• Believing tests run outside the browser
• Assuming manual test runs only

2. Which of the following is the correct way to start a Cypress test block?

easy

A. test('My test', () => { ... })

B. describe('My test', () => { ... })

C. it('My test', () => { ... })

D. run('My test', () => { ... })

Solution

1. Step 1: Recall Cypress test syntax

   Cypress uses it() to define individual test cases inside describe() blocks.

2. Step 2: Identify correct test block starter

   it() is the function to start a test case. describe() groups tests, but does not start a test itself.

3. Final Answer:

   it('My test', () => { ... }) -> Option C

4. Quick Check:

   Test case starts with it() = A [OK]

Hint: Tests start with it(), groups with describe() [OK]

Common Mistakes:

• Using test() which is not Cypress syntax
• Confusing describe() as test starter
• Using run() which does not exist

3. Given the code:

cy.visit('https://example.com')
cy.get('button').click()
cy.url().should('include', '/dashboard')

What will this test check?

medium

A. That clicking the button navigates to a URL containing '/dashboard'

B. That the button is visible on the page

C. That the page title contains 'dashboard'

D. That the button is disabled

Solution

1. Step 1: Analyze each Cypress command

   cy.visit() opens the page, cy.get('button').click() clicks the button, and cy.url().should('include', '/dashboard') asserts the URL includes '/dashboard'.

2. Step 2: Understand the assertion

   The assertion checks if after clicking the button, the URL changes to include '/dashboard', indicating navigation.

3. Final Answer:

   That clicking the button navigates to a URL containing '/dashboard' -> Option A

4. Quick Check:

   URL includes '/dashboard' after click = B [OK]

Hint: Look at the assertion on cy.url() for navigation check [OK]

Common Mistakes:

• Thinking it checks button visibility
• Confusing URL check with page title
• Assuming button is disabled

4. Identify the error in this Cypress test code:

describe('Login test', () => {
  it('logs in user', () => {
    cy.visit('https://app.com')
    cy.get('#username').type('user1')
    cy.get('#password').type('pass123')
    cy.get('button.submit').click
    cy.url().should('include', '/home')
  })
})

medium

A. Wrong selector for username input

B. Missing parentheses after click method

C. cy.visit URL is incorrect

D. Missing assertion after typing password

Solution

1. Step 1: Check method calls in the code

   The line cy.get('button.submit').click misses parentheses, so the click method is not called.

2. Step 2: Verify other parts

   Selectors and URL look valid, and assertion after typing password is not required. The main error is missing parentheses on click.

3. Final Answer:

   Missing parentheses after click method -> Option B

4. Quick Check:

   Method calls need () = A [OK]

Hint: Check all method calls have () after them [OK]

Common Mistakes:

• Ignoring missing parentheses on click
• Assuming selector is wrong without checking
• Thinking cy.visit URL is invalid

5. Why does Cypress provide real-time test results and automatic waiting, making it ideal for modern web apps?

hard

A. Because it controls the browser and app in the same run loop

B. Because it requires explicit waits for every action

C. Because it runs outside the browser and uses manual waits

D. Because it only supports static HTML pages

Solution

1. Step 1: Understand Cypress architecture

   Cypress runs inside the browser and shares the same run loop as the app, allowing it to control and observe app behavior closely.

2. Step 2: Explain real-time results and automatic waits

   This architecture lets Cypress automatically wait for elements and commands, and show test results live without manual delays.

3. Final Answer:

   Because it controls the browser and app in the same run loop -> Option A

4. Quick Check:

   Same run loop control = C [OK]

Hint: Same run loop means automatic waits and live results [OK]

Common Mistakes:

• Thinking Cypress runs outside browser
• Assuming manual waits are needed
• Believing it only supports static pages