Props and event testing in Cypress - Framework Patterns

Framework Mode - Props and event testing

Folder Structure

    cypress/
    ├── e2e/                  # Test specs for end-to-end and component tests
    │   ├── components/        # Component tests focusing on props and events
    │   │   └── Button.cy.js   # Example test for a Button component
    │   └── pages/             # Page-level tests
    ├── fixtures/              # Static test data (JSON files)
    ├── support/               # Custom commands and utilities
    │   ├── commands.js        # Custom Cypress commands
    │   └── index.js           # Support file loaded before tests
    ├── plugins/               # Cypress plugins if needed
    └── cypress.config.js      # Main Cypress configuration file
    

Test Framework Layers

• Test Specs (e2e/components): Write tests that mount components, pass props, and simulate events.
• Support Layer: Contains reusable commands to simulate user actions and assert event calls.
• Fixtures: Store test data for props or event payloads to keep tests clean.
• Plugins: Extend Cypress capabilities if needed (e.g., for component testing).
• Configuration: Manage environment settings, base URLs, and test options.

Configuration Patterns

• cypress.config.js: Define baseUrl, component testing setup, and environment variables.
• Environment Variables: Use env property for credentials or flags to toggle event logging.
• Component Testing Setup: Configure component testing with framework adapter (e.g., React).
• Fixtures: Use JSON files to store props data or expected event payloads for reuse.

Test Reporting and CI/CD Integration

• Use Cypress built-in reporter for clear pass/fail results of prop and event tests.
• Integrate with CI tools (GitHub Actions, Jenkins) to run tests on pull requests and merges.
• Generate HTML or JSON reports with mochawesome or similar reporters for detailed insights.
• Fail builds if critical prop or event tests fail to ensure UI components behave correctly.

Best Practices

1. Isolate Components: Test components independently by passing props directly to verify rendering and behavior.
2. Simulate Real User Events: Use Cypress commands like click(), type() to trigger events and assert handlers are called.
3. Use Spies and Stubs: Spy on event handler functions to confirm they are called with correct arguments.
4. Keep Tests Deterministic: Avoid flaky tests by waiting for UI updates and using explicit assertions.
5. Reuse Test Data: Store props and event payloads in fixtures to keep tests clean and maintainable.

Self Check

Where in this folder structure would you add a new test file to verify that a custom Modal component correctly emits a close event when the close button is clicked?

Key Result

Organize Cypress tests by separating component specs, support utilities, fixtures, and configuration to efficiently test props and events.

Practice

1. What is the main purpose of props testing in Cypress component tests?

easy

A. To verify that components receive and display data correctly

B. To check if the component's CSS styles are applied

C. To test if the component renders without errors

D. To measure the performance of component rendering

Solution

1. Step 1: Understand what props are

   Props are data passed to components to control their behavior or display.

2. Step 2: Identify the goal of props testing

   Props testing ensures the component uses and shows this data correctly.

3. Final Answer:

   To verify that components receive and display data correctly -> Option A

4. Quick Check:

   Props testing = verify data usage [OK]

Hint: Props testing checks data passed to components [OK]

Common Mistakes:

• Confusing props testing with style or performance testing
• Thinking props testing checks event handlers
• Assuming props testing is about rendering errors

2. Which Cypress command is used to spy on an event handler function passed as a prop?

easy

A. cy.spy()

B. cy.stub()

C. cy.mount()

D. cy.visit()

Solution

1. Step 1: Recall Cypress commands for spying

   cy.spy() creates a spy to watch function calls without changing behavior.

2. Step 2: Match command to event handler spying

   Spying on event handlers uses cy.spy() to check if they were called.

3. Final Answer:

   cy.spy() -> Option A

4. Quick Check:

   Spy event handler = cy.spy() [OK]

Hint: Use cy.spy() to watch function calls [OK]

Common Mistakes:

• Using cy.stub() which replaces function behavior
• Confusing cy.mount() with spying
• Using cy.visit() which is for page navigation

3. Given this Cypress test snippet:

const onClick = cy.spy();
cy.mount();
cy.get('button').click();
expect(onClick).to.have.been.calledOnce();

What will be the test result?

medium

A. Test passes because the click triggers onClick once

B. Test passes but onClick is called multiple times

C. Test fails because onClick is never called

D. Test fails due to syntax error in expect statement

Solution

1. Step 1: Analyze the spy and mount setup

   onClick is a spy passed as prop; Button is mounted with it.

2. Step 2: Check the assertion syntax

   The assertion uses calledOnce() which is incorrect syntax; it should be calledOnce without parentheses.

3. Final Answer:

   Test fails due to syntax error in expect statement -> Option D

4. Quick Check:

   calledOnce() is invalid syntax [OK]

Hint: Use calledOnce without () in assertions [OK]

Common Mistakes:

• Adding parentheses after calledOnce
• Assuming spy is not called when it is
• Ignoring syntax errors in assertions

4. You wrote this Cypress test to check a button click event:

const onClick = cy.spy();
cy.mount();
cy.get('button').click();
expect(onClick).to.have.been.called();

The test fails. What is the likely problem?

medium

A. The spy was not created correctly with cy.spy()

B. The event handler prop name is wrong

C. The assertion incorrectly uses parentheses after called

D. The button selector is incorrect

Solution

1. Step 1: Check spy creation and usage

   Spy is created correctly with cy.spy() and passed as prop.

2. Step 2: Review assertion syntax

   called is a property, not a function, so no parentheses should be used; parentheses cause failure.

3. Final Answer:

   The assertion incorrectly uses parentheses after called -> Option C

4. Quick Check:

   called is property, no () [OK]

Hint: Don't add () after called in assertions [OK]

Common Mistakes:

• Using called() instead of called
• Incorrect selector causing no click
• Wrong prop name like onClickHandler

5. You want to test a component that receives a disabled prop and an onSubmit event handler prop. Which Cypress test approach correctly verifies that clicking the submit button calls onSubmit only when disabled is false?

hard

A. Mount component with disabled=true and spy on onSubmit; click button and assert spy called once; then mount with disabled=false and assert spy not called

B. Mount component with disabled=false and spy on onSubmit; click button and assert spy called once; then mount with disabled=true and assert spy not called on click

C. Mount component once with disabled=false and spy on onSubmit; click button twice and assert spy called twice regardless of disabled prop

D. Mount component with disabled=false without spy; click button and check UI changes only

Solution

1. Step 1: Test enabled state with spy

   Mount with disabled=false, spy on onSubmit, click button, expect spy called once.

2. Step 2: Test disabled state with spy

   Mount with disabled=true, click button, expect spy not called to confirm no event triggered.

3. Final Answer:

   Mount component with disabled=false and spy on onSubmit; click button and assert spy called once; then mount with disabled=true and assert spy not called on click -> Option B

4. Quick Check:

   Test both states with spy to confirm event firing [OK]

Hint: Test enabled and disabled states separately with spy [OK]

Common Mistakes:

• Testing only one disabled state
• Not using spy to check event calls
• Assuming event fires regardless of disabled prop