Component testing vs E2E in Cypress - Framework Approaches Compared

Framework Mode - Component testing vs E2E

Folder Structure for Cypress Testing Framework

  cypress.config.js         # Cypress configuration file
  
  cypress/
  ├── e2e/                  # End-to-End test specs
  │   ├── login.cy.js       # E2E test example
  │   └── dashboard.cy.js
  ├── component/            # Component test specs
  │   ├── button.cy.js      # Component test example
  │   └── modal.cy.js
  ├── fixtures/             # Test data files
  │   └── user.json
  └── support/              # Support files and commands
      ├── commands.js       # Custom commands
      ├── e2e.js            # E2E support setup
      └── component.js      # Component support setup
  

Test Framework Layers

• Test Specs: Separate folders for component and e2e tests to keep tests organized by scope.
• Support Layer: Contains reusable commands and setup files for both component and E2E tests.
• Fixtures: Static test data used by tests to keep data consistent and reusable.
• Configuration: Central place to define environment settings, browser options, and test behavior.

Configuration Patterns

Use cypress.config.js to define settings for both component and E2E tests.

  import { defineConfig } from 'cypress'

  export default defineConfig({
    e2e: {
      baseUrl: 'https://myapp.example.com',
      supportFile: 'cypress/support/e2e.js',
      specPattern: 'cypress/e2e/**/*.cy.js',
      env: {
        username: 'testuser',
        password: 'password123'
      }
    },
    component: {
      devServer: {
        framework: 'react',
        bundler: 'webpack'
      },
      supportFile: 'cypress/support/component.js',
      specPattern: 'cypress/component/**/*.cy.js'
    }
  })
  

Use environment variables or separate config files for different environments (dev, staging, prod).

Test Reporting and CI/CD Integration

• Use built-in Cypress reporters or plugins like mochawesome for detailed HTML reports.
• Integrate Cypress tests into CI pipelines (GitHub Actions, Jenkins, GitLab CI) to run tests on every code push.
• Separate jobs for component and E2E tests to optimize test run time and isolate failures.
• Use Cypress Dashboard service for test analytics and video recordings of test runs.

Best Practices for Component Testing vs E2E Framework

• Separate Test Types: Keep component and E2E tests in different folders and configs for clarity and faster runs.
• Reuse Support Code: Share common commands and utilities but customize support files for each test type.
• Isolate Component Tests: Test UI components in isolation without backend dependencies for fast, reliable feedback.
• Use Realistic E2E Tests: Test full user flows including backend and UI to catch integration issues.
• Data Management: Use fixtures and environment variables to keep test data consistent and secure.

Self Check Question

Where in this folder structure would you add a new component test for a custom dropdown menu?

Key Result

Organize Cypress tests by separating component and E2E tests with dedicated folders, configs, and support files for clear, maintainable, and efficient testing.

Practice

1. What is the main focus of component testing in Cypress?

easy

A. Testing the entire app flow from start to finish

B. Testing individual parts of the app in isolation

C. Checking the app's performance under load

D. Verifying database connections

Solution

1. Step 1: Understand component testing scope

   Component testing focuses on small parts or components of the app, testing them alone without the full app context.

2. Step 2: Compare with other testing types

   E2E testing checks the whole app working together, so it is not the focus of component testing.

3. Final Answer:

   Testing individual parts of the app in isolation -> Option B

4. Quick Check:

   Component testing = isolated parts [OK]

Hint: Component testing isolates parts, not full app [OK]

Common Mistakes:

• Confusing component testing with E2E testing
• Thinking component testing checks full app flow
• Assuming component testing checks performance

2. Which of the following is the correct Cypress command to mount a React component for component testing?

easy

A. cy.visit('/component')

B. cy.request('/api/component')

C. cy.mount()

D. cy.get('MyComponent').click()

Solution

1. Step 1: Identify component testing command

   In Cypress component testing, cy.mount() is used to render a component in isolation.

2. Step 2: Eliminate other commands

   cy.visit() is for E2E page visits, cy.get() selects elements, and cy.request() makes HTTP calls, none mount components.

3. Final Answer:

   cy.mount(<MyComponent />) -> Option C

4. Quick Check:

   Mount component = cy.mount() [OK]

Hint: Use cy.mount() to render components in tests [OK]

Common Mistakes:

• Using cy.visit() for component testing
• Confusing cy.get() with mounting
• Trying to mount components with cy.request()

3. Given this Cypress E2E test code, what will be the output in the test report?

describe('Login flow', () => {
  it('should show error on wrong password', () => {
    cy.visit('/login')
    cy.get('input[name="username"]').type('user1')
    cy.get('input[name="password"]').type('wrongpass')
    cy.get('button[type="submit"]').click()
    cy.contains('Invalid credentials').should('be.visible')
  })
})

medium

A. Test passes without checking any message

B. Test fails because cy.visit() is not allowed in E2E

C. Test fails due to syntax error in selectors

D. Test passes if 'Invalid credentials' message appears

Solution

1. Step 1: Analyze test steps

   The test visits the login page, enters username and wrong password, clicks submit, then checks for error message visibility.

2. Step 2: Verify correctness of commands

   All commands are valid Cypress E2E commands. The assertion checks if the error message is visible, so test passes if message appears.

3. Final Answer:

   Test passes if 'Invalid credentials' message appears -> Option D

4. Quick Check:

   E2E test passes if error message visible [OK]

Hint: E2E tests check full flow and visible messages [OK]

Common Mistakes:

• Thinking cy.visit() is invalid in E2E
• Ignoring the assertion on error message
• Assuming syntax errors in selectors without cause

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

import MyButton from './MyButton'
describe('MyButton component', () => {
  it('renders button text', () => {
    cy.mount(MyButton)
    cy.get('button').should('contain.text', 'Click me')
  })
})

medium

A. Missing JSX syntax when mounting component

B. cy.get selector is incorrect

C. cy.mount cannot be used in component tests

D. No assertion is present

Solution

1. Step 1: Check component mounting syntax

   In Cypress component testing, components must be mounted using JSX syntax like cy.mount(<MyButton />), not just the component name.

2. Step 2: Verify other parts

   The selector cy.get('button') and assertion are correct. cy.mount is valid in component tests.

3. Final Answer:

   Missing JSX syntax when mounting component -> Option A

4. Quick Check:

   Use JSX syntax in cy.mount() [OK]

Hint: Always wrap component in <> when mounting [OK]

Common Mistakes:

• Passing component without JSX syntax to cy.mount
• Thinking cy.mount is invalid in component tests
• Misreading selector as incorrect

5. You want to test a login form component in isolation but also verify the full login flow including navigation. Which Cypress testing approach should you use for each task?

hard

A. Use component testing for form UI; use E2E testing for full login flow

B. Use E2E testing for form UI; use component testing for full login flow

C. Use only component testing for both tasks

D. Use only E2E testing for both tasks

Solution

1. Step 1: Match testing types to tasks

   Component testing is best for isolated UI parts like the login form component itself.

2. Step 2: Use E2E for full app flow

   To verify the entire login flow including navigation and backend, E2E testing is appropriate.

3. Final Answer:

   Use component testing for form UI; use E2E testing for full login flow -> Option A

4. Quick Check:

   Component = UI parts, E2E = full flow [OK]

Hint: Component tests parts; E2E tests whole app flow [OK]

Common Mistakes:

• Mixing up which test type suits UI vs full flow
• Trying to test full flow with component tests
• Ignoring navigation in login flow testing