Component test setup in Cypress - Framework Patterns

Framework Mode - Component test setup

Folder Structure

  cypress/
  ├── e2e/                  # End-to-end tests
  ├── component/            # Component tests
  │   ├── Button.cy.js      # Example component test file
  │   └── Header.cy.js
  ├── support/              # Support files and commands
  │   ├── commands.js       # Custom commands
  │   └── component.js      # Component test support setup
  ├── fixtures/             # Test data files
  └── cypress.config.js     # Cypress configuration file
  

Test Framework Layers

• Component Tests: Located in cypress/component/, these test individual UI components in isolation.
• Support Layer: cypress/support/component.js sets up the environment for component testing, including mounting utilities.
• Fixtures: Static test data stored in cypress/fixtures/ to keep tests clean and reusable.
• Configuration: cypress.config.js defines environment settings, test types, and component testing options.

Configuration Patterns

Use cypress.config.js to configure component testing:

  import { defineConfig } from 'cypress'

  export default defineConfig({
    component: {
      devServer: {
        framework: 'react',
        bundler: 'webpack'
      },
      supportFile: 'cypress/support/component.js'
    },
    env: {
      baseUrl: 'http://localhost:3000',
      apiUrl: 'https://api.example.com'
    },
    retries: 1
  })
  

Use environment variables for URLs and credentials to keep tests flexible across environments.

Test Reporting and CI/CD Integration

• Use Cypress built-in reporters like spec or integrate with mochawesome for detailed HTML reports.
• Configure CI pipelines (GitHub Actions, GitLab CI, Jenkins) to run cypress run --component for component tests.
• Save test artifacts like screenshots and videos on failure for debugging.
• Fail the build if any component test fails to ensure quality.

Best Practices

1. Isolate Components: Test components independently without relying on the full app to catch issues early.
2. Use Support Files: Centralize mounting logic and custom commands in support/component.js for reuse.
3. Keep Tests Small: Write focused tests for one component behavior at a time.
4. Mock External Calls: Avoid real network calls by stubbing APIs to keep tests fast and reliable.
5. Use Fixtures: Store test data separately to keep tests clean and easy to update.

Self Check

Where in this folder structure would you add a new component test file for a LoginForm component?

Key Result

Organize component tests in a dedicated folder with support files and config for isolated, fast UI testing.

Practice

1. What is the main purpose of using mount() in Cypress component testing?

easy

A. To write unit tests for backend APIs

B. To run end-to-end tests on the whole application

C. To load a component inside Cypress for testing

D. To deploy the application to a server

Solution

1. Step 1: Understand the role of mount()

   mount() is used to load a UI component inside Cypress so you can test it in isolation.

2. Step 2: Differentiate from other test types

   End-to-end tests run the whole app, but mount() focuses on small parts (components).

3. Final Answer:

   To load a component inside Cypress for testing -> Option C

4. Quick Check:

   mount() loads component [OK]

Hint: Remember: mount() loads components, not full apps [OK]

Common Mistakes:

• Confusing mount() with full app testing
• Thinking mount() deploys code
• Mixing component and API testing

2. Which of the following is the correct syntax to prepare a component before each test in Cypress?

easy

A. beforeEach(() => { mount() })

B. beforeAll(() => { mount() })

C. afterEach(() => { mount() })

D. before(() => { mount() })

Solution

1. Step 1: Identify the correct hook for setup before each test

   beforeEach() runs before every test, ideal for fresh component setup.

2. Step 2: Confirm syntax correctness

   The syntax beforeEach(() => { mount(<MyComponent />) }) correctly mounts the component before each test.

3. Final Answer:

   beforeEach(() => { mount(<MyComponent />) }) -> Option A

4. Quick Check:

   Use beforeEach() for setup [OK]

Hint: Use beforeEach() to reset component before every test [OK]

Common Mistakes:

• Using beforeAll() which runs only once
• Using afterEach() which runs after tests
• Using before() which is deprecated in Cypress

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

describe('Button component', () => {
  beforeEach(() => {
    mount(Click me)
  })

  it('checks button text', () => {
    cy.get('button').should('have.text', 'Click me')
  })
})

medium

A. Test passes because button text matches

B. Test fails because button text is missing

C. Test errors due to wrong selector syntax

D. Test is skipped because mount() is missing

Solution

1. Step 1: Analyze the mount and selector

   The mount() loads a button with text 'Click me'. The selector cy.get('button') correctly targets it.

2. Step 2: Check the assertion

   The assertion should('have.text', 'Click me') matches the button's text exactly, so it passes.

3. Final Answer:

   Test passes because button text matches -> Option A

4. Quick Check:

   Correct selector and text = pass [OK]

Hint: Match selector text exactly for passing assertion [OK]

Common Mistakes:

• Using wrong selector causing no element found
• Mismatching text in assertion
• Forgetting to mount component before test

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

describe('Input component', () => {
  beforeEach(() => {
    mount('')
  })

  it('checks placeholder', () => {
    cy.get('input').should('have.attr', 'placeholder', 'Enter name')
  })
})

medium

A. beforeEach() should be replaced with afterEach()

B. mount() should receive JSX, not a string

C. cy.get() selector is incorrect

D. The placeholder attribute is misspelled

Solution

1. Step 1: Check the argument passed to mount()

   The code passes a string '<input placeholder="Enter name" />' instead of JSX element. mount() expects JSX, not a string.

2. Step 2: Confirm other parts are correct

   The selector cy.get('input') and attribute check are correct, so no error there.

3. Final Answer:

   mount() should receive JSX, not a string -> Option B

4. Quick Check:

   mount() needs JSX, not string [OK]

Hint: Pass JSX, not strings, to mount() [OK]

Common Mistakes:

• Passing HTML strings instead of JSX to mount()
• Confusing beforeEach() with afterEach()
• Using wrong selectors

5. You want to test a component that renders a list of items passed as props. Which setup correctly mounts the component with props before each test?

hard

A. beforeEach(() => { mount() })

B. beforeEach(() => { mount('') })

C. beforeEach(() => { mount(List, { props: { items: ["a", "b"] } }) })

D. beforeEach(() => { mount() })

Solution

1. Step 1: Understand correct JSX with props

   Passing props in JSX uses syntax like <List items={["a", "b"]} />. This is correct in beforeEach(() => { mount(<List items={["a", "b"]} />) }).

2. Step 2: Identify incorrect options

   beforeEach(() => { mount('<List items=["a", "b"] />') }) passes a string, not JSX. beforeEach(() => { mount(List, { props: { items: ["a", "b"] } }) }) uses wrong mount signature. beforeEach(() => { mount(<List items="a,b" />) }) passes a string instead of array.

3. Final Answer:

   beforeEach(() => { mount(<List items={["a", "b"]} />) }) -> Option D

4. Quick Check:

   Use JSX with array props [OK]

Hint: Pass props as JSX arrays, not strings [OK]

Common Mistakes:

• Passing component as string instead of JSX
• Using wrong mount function signature
• Passing props as comma-separated string