Cypress architecture (runs in browser) - Framework Patterns

Framework Mode - Cypress architecture (runs in browser)

Folder Structure

  cypress/
  ├── e2e/                 # Test files (end-to-end tests)
  │   ├── login.cy.js      # Example test for login
  │   └── dashboard.cy.js  # Example test for dashboard
  ├── fixtures/            # Static test data (JSON, images)
  │   └── user.json
  ├── support/             # Custom commands and reusable code
  │   ├── commands.js      # Custom Cypress commands
  │   └── e2e.js           # Global support file loaded before tests
  └── videos/              # Automatically saved test run videos

  cypress.config.js        # Main Cypress configuration file
  package.json             # Project dependencies and scripts
  

Test Framework Layers

• Test Layer (cypress/e2e): Contains test scripts written in JavaScript. These describe user actions and assertions.
• Support Layer (cypress/support): Holds reusable commands and setup code that runs before tests. Helps avoid repetition.
• Fixtures Layer (cypress/fixtures): Stores static data files like JSON to use as test data inputs.
• Configuration Layer (cypress.config.js): Defines environment settings, base URLs, browser options, and test behavior.
• Plugins Layer (optional): For extending Cypress with Node.js code, e.g., custom tasks or preprocessors.

Configuration Patterns

Cypress uses cypress.config.js to manage settings:

• Base URL: Set the main website URL to avoid repeating it in tests.
• Environment Variables: Use env property for credentials or feature flags, accessed via Cypress.env().
• Browser Selection: Specify browser in CLI or config for cross-browser testing.
• Test Files Pattern: Define which files to run as tests.
• Retries and Timeouts: Configure automatic retries and command timeouts for stability.

Example snippet from cypress.config.js:

  import { defineConfig } from 'cypress'

  export default defineConfig({
    e2e: {
      baseUrl: 'https://example.com',
      env: {
        username: 'testuser',
        password: 'secret'
      },
      retries: 2,
      setupNodeEvents(on, config) {
        // implement node event listeners here
      }
    }
  })
  

Test Reporting and CI/CD Integration

• Built-in Reporter: Cypress shows test results in the Test Runner UI with clear pass/fail status.
• Command Line Reports: Use reporters like mochawesome for detailed HTML or JSON reports.
• Video and Screenshots: Automatically record videos and screenshots on test failures for debugging.
• CI/CD Integration: Run Cypress tests in pipelines (GitHub Actions, Jenkins, GitLab) using CLI commands.
  • Use headless mode (cypress run) for automated runs.
  • Publish reports and artifacts for team review.

Best Practices

1. Use Page Object Pattern: Organize selectors and actions in separate files inside support or e2e folders to keep tests clean.
2. Leverage Custom Commands: Create reusable commands in commands.js to avoid repeating code.
3. Keep Tests Independent: Each test should run alone without relying on others to avoid flaky results.
4. Use Fixtures for Test Data: Store static data separately to make tests easier to maintain and update.
5. Explicit Assertions: Always assert expected outcomes clearly to catch failures early.

Self Check

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

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

Key Result

Cypress test framework runs tests inside the browser with clear folder layers for tests, support code, fixtures, and config.

Practice

1. What is a key feature of Cypress architecture regarding where tests run?

easy

A. Tests run on a cloud service without local browser access.

B. Tests run only on the server without browser interaction.

C. Tests run in a separate virtual machine outside the browser.

D. Tests run inside the browser, controlling the app like a real user.

Solution

1. Step 1: Understand Cypress test execution environment

   Cypress runs tests directly inside the browser, allowing it to control and observe the app as a user would.

2. Step 2: Compare with other options

   Other options describe architectures not used by Cypress, such as server-only or cloud-only test runs.

3. Final Answer:

   Tests run inside the browser, controlling the app like a real user. -> Option D

4. Quick Check:

   Cypress tests run in browser = A [OK]

Hint: Remember: Cypress tests run inside the browser environment [OK]

Common Mistakes:

• Thinking tests run only on the server
• Assuming tests run outside the browser
• Confusing Cypress with cloud-only test runners

2. Which of the following is the correct way to write a Cypress command to visit a webpage?

easy

A. cy.visit('https://example.com')

B. visit.cy('https://example.com')

C. cy.goTo('https://example.com')

D. browser.visit('https://example.com')

Solution

1. Step 1: Recall Cypress command syntax

   Cypress commands start with cy. followed by the command name, so cy.visit() is correct.

2. Step 2: Check other options for syntax errors

   Options A, B, and D use incorrect method names or object references not valid in Cypress.

3. Final Answer:

   cy.visit('https://example.com') -> Option A

4. Quick Check:

   Correct Cypress command syntax = C [OK]

Hint: Cypress commands always start with 'cy.' [OK]

Common Mistakes:

• Swapping method and object order
• Using non-existent Cypress commands
• Using browser object instead of cy

3. Given the following Cypress test code, what will be the output in the test runner?

describe('My Test', () => {
  it('checks page title', () => {
    cy.visit('https://example.cypress.io')
    cy.title().should('include', 'Kitchen')
  })
})

medium

A. Test throws a syntax error due to missing semicolons.

B. Test passes if the page title includes 'Kitchen'.

C. Test passes regardless of the page title content.

D. Test fails because cy.title() is not a valid command.

Solution

1. Step 1: Understand the test steps

   The test visits the Cypress example page and asserts the page title includes the word 'Kitchen'.

2. Step 2: Validate command correctness and assertion

   cy.title() is a valid Cypress command that gets the page title. The assertion should('include', 'Kitchen') checks if the title contains 'Kitchen'.

3. Final Answer:

   Test passes if the page title includes 'Kitchen'. -> Option B

4. Quick Check:

   cy.title() assertion success = D [OK]

Hint: cy.title() gets page title; check with should() [OK]

Common Mistakes:

• Thinking cy.title() is invalid
• Ignoring assertion logic
• Confusing syntax errors with missing semicolons

4. Identify the error in this Cypress test code snippet:

it('checks button click', () => {
  cy.visit('https://example.com')
  cy.get('#submit').click
})

medium

A. Incorrect selector syntax for cy.get().

B. cy.visit() should be inside beforeEach block.

C. Missing parentheses after click command.

D. Using cy.get() without chaining should() causes error.

Solution

1. Step 1: Review the click command usage

   The click command must be called as a function with parentheses: click().

2. Step 2: Check other parts of the code

   The selector #submit is valid, cy.visit() can be inside the test, and chaining should() is optional.

3. Final Answer:

   Missing parentheses after click command. -> Option C

4. Quick Check:

   click() needs parentheses = B [OK]

Hint: Always call commands like click() with parentheses [OK]

Common Mistakes:

• Forgetting parentheses on commands
• Misunderstanding selector syntax
• Thinking visit() must be in beforeEach

5. Why does Cypress run tests inside the browser instead of outside it, and what advantage does this provide?

hard

A. Running inside the browser allows Cypress to control the app like a user, making tests faster and easier to debug.

B. Running inside the browser reduces network traffic by avoiding server calls.

C. Running outside the browser is impossible due to browser security restrictions.

D. Running inside the browser enables tests to run without any JavaScript.

Solution

1. Step 1: Understand Cypress architecture purpose

   Cypress runs tests inside the browser to interact with the app as a real user would, giving precise control and observation.

2. Step 2: Identify benefits of this approach

   This approach makes tests fast, reliable, and easy to debug because Cypress can directly access the app's DOM and network.

3. Final Answer:

   Running inside the browser allows Cypress to control the app like a user, making tests faster and easier to debug. -> Option A

4. Quick Check:

   Browser test run = faster, easier debug = A [OK]

Hint: Tests inside browser = real user control + fast debugging [OK]

Common Mistakes:

• Thinking tests run outside browser for speed
• Confusing network traffic with test speed
• Believing tests run without JavaScript