Bird
Raised Fist0
Cypresstesting~8 mins

Responsive breakpoint testing in Cypress - Framework Patterns

Choose your learning style10 modes available
Framework Mode - Responsive breakpoint testing
Folder Structure
cypress/
├── e2e/                  # Test specs organized by feature
│   ├── responsive/       # Responsive breakpoint tests
│   │   └── homepage.cy.js
│   └── login.cy.js
├── fixtures/             # Test data files (JSON, etc.)
│   └── users.json
├── support/              # Custom commands and reusable utilities
│   ├── commands.js
│   └── index.js
cypress.config.js         # Main Cypress configuration file
package.json             # Project dependencies and scripts
Test Framework Layers
  • Test Specs (cypress/e2e/responsive/): Contains tests that check UI behavior at different screen sizes (breakpoints).
  • Support Layer (cypress/support/): Holds reusable commands like setting viewport sizes or custom assertions for responsiveness.
  • Fixtures (cypress/fixtures/): Stores test data such as user info or expected layout data.
  • Configuration (cypress.config.js): Defines environment settings, base URLs, and viewport presets.
Configuration Patterns
  • Viewport Sizes: Define common breakpoints in cypress.config.js or support commands for reuse (e.g., mobile, tablet, desktop widths).
  • Environment Variables: Use env in config or CLI to switch base URLs or credentials for different environments.
  • Custom Commands: Create commands like cy.setBreakpoint('mobile') to set viewport easily in tests.
// Example snippet from cypress.config.js
const { defineConfig } = require('cypress');

const viewports = {
  mobile: { width: 375, height: 667 },
  tablet: { width: 768, height: 1024 },
  desktop: { width: 1280, height: 800 }
};

module.exports = defineConfig({
  e2e: {
    baseUrl: 'https://example.com',
    env: {
      viewports
    },
    setupNodeEvents(on, config) {
      // implement node event listeners here
    }
  }
});
Test Reporting and CI/CD Integration
  • Test Reports: Use Cypress built-in reporter or integrate with tools like Mochawesome for detailed HTML reports showing pass/fail per breakpoint.
  • Screenshots & Videos: Enable automatic screenshots and video recording on test failures to help debug responsive issues.
  • CI/CD: Integrate Cypress tests in pipelines (GitHub Actions, Jenkins) to run breakpoint tests on every pull request or deployment.
  • Parallelization: Run tests in parallel across different viewport sizes to speed up feedback.
Best Practices
  1. Use Reusable Viewport Settings: Define breakpoints once and reuse them to keep tests consistent and easy to update.
  2. Test Critical Pages at All Breakpoints: Focus on key user flows and pages to ensure UI works well on all devices.
  3. Use Custom Commands for Readability: Abstract viewport changes into commands like cy.setBreakpoint('tablet') for clear test steps.
  4. Keep Tests Independent: Each test should set its own viewport to avoid flaky results.
  5. Leverage Visual Testing Tools: Consider adding visual snapshot comparisons to catch layout shifts across breakpoints.
Self Check

Where in this folder structure would you add a new custom command to set viewport sizes for responsive breakpoint testing?

Key Result
Organize Cypress tests with dedicated folders for responsive specs, reusable viewport commands, and environment-based configurations to ensure reliable breakpoint testing.

Practice

(1/5)
1. What is the main purpose of using cy.viewport() in Cypress tests?
easy
A. To capture screenshots of the current page
B. To speed up test execution by skipping UI rendering
C. To mock API responses during tests
D. To simulate different screen sizes for responsive testing

Solution

  1. Step 1: Understand cy.viewport() role

    cy.viewport() changes the browser size to simulate devices.
  2. Step 2: Identify its use in responsive testing

    This helps check if UI adapts correctly on phones, tablets, and desktops.
  3. Final Answer:

    To simulate different screen sizes for responsive testing -> Option D
  4. Quick Check:

    cy.viewport() = simulate screen sizes [OK]
Hint: Remember: viewport changes screen size for layout checks [OK]
Common Mistakes:
  • Confusing viewport with API mocking
  • Thinking it speeds up tests by skipping UI
  • Assuming it captures screenshots
2. Which of the following is the correct syntax for the iPhone 6 viewport preset in Cypress?
easy
A. cy.viewport('iphone-6')
B. cy.viewport(375, 667)
C. cy.viewport('iPhone6')
D. cy.setViewport('iphone-6')

Solution

  1. Step 1: Recall Cypress viewport presets

    Cypress supports device names like 'iphone-6' in cy.viewport().
  2. Step 2: Check syntax correctness

    cy.viewport('iphone-6') uses correct method and exact device name string.
  3. Final Answer:

    cy.viewport('iphone-6') -> Option A
  4. Quick Check:

    Correct device name string in cy.viewport() [OK]
Hint: Use exact device names in quotes with cy.viewport() [OK]
Common Mistakes:
  • Using wrong method name like cy.setViewport()
  • Incorrect device name casing or spelling
  • Passing numbers without quotes for presets
3. What will be the result of this Cypress test snippet?
cy.viewport('ipad-2')
cy.get('.menu').should('be.visible')
medium
A. Test ignores viewport and checks .menu visibility on default size
B. Test passes if .menu is visible on iPad 2 screen size
C. Test throws syntax error due to missing semicolon
D. Test fails because 'ipad-2' is not a valid viewport preset

Solution

  1. Step 1: Understand viewport preset 'ipad-2'

    'ipad-2' is a valid Cypress preset simulating iPad 2 screen size.
  2. Step 2: Analyze assertion behavior

    The test checks if element with class .menu is visible at that size.
  3. Final Answer:

    Test passes if .menu is visible on iPad 2 screen size -> Option B
  4. Quick Check:

    Valid preset + visibility check = pass if visible [OK]
Hint: Valid preset means viewport changes; assertion checks visibility [OK]
Common Mistakes:
  • Thinking 'ipad-2' is invalid preset
  • Assuming missing semicolons cause errors in Cypress
  • Believing viewport is ignored without explicit reload
4. Identify the error in this Cypress test for responsive breakpoint:
cy.viewport(1024, 768)
cy.get('#nav').should('be.visible')
cy.viewport('mobile')
cy.get('#nav').should('not.be.visible')
medium
A. Incorrect selector '#nav' should be '.nav'
B. Missing wait between viewport changes causes flaky test
C. Invalid viewport preset 'mobile' causes test failure
D. Assertions are reversed; nav should be visible on mobile

Solution

  1. Step 1: Check viewport presets used

    1024x768 is valid, but 'mobile' is not a recognized preset in Cypress.
  2. Step 2: Understand impact of invalid preset

    Using 'mobile' causes Cypress to throw an error and fail the test.
  3. Final Answer:

    Invalid viewport preset 'mobile' causes test failure -> Option C
  4. Quick Check:

    Use only valid viewport presets [OK]
Hint: Use only Cypress documented viewport presets [OK]
Common Mistakes:
  • Assuming 'mobile' is a valid preset
  • Thinking missing waits cause failure here
  • Confusing selector correctness with viewport issues
5. You want to test a web page's header visibility on desktop (1440x900) and mobile (375x667). Which is the best Cypress test approach?
hard
A. Write two separate tests using cy.viewport(1440, 900) and cy.viewport(375, 667) with visibility assertions
B. Write one test with cy.viewport(1440, 900) only, assuming mobile works the same
C. Use cy.viewport('iphone-x') only, ignoring desktop size
D. Test only on default viewport size without changing viewport

Solution

  1. Step 1: Understand responsive testing goal

    We want to verify header visibility on both desktop and mobile screen sizes.
  2. Step 2: Choose best Cypress approach

    Writing separate tests with explicit viewport sizes ensures coverage of both layouts.
  3. Final Answer:

    Write two separate tests using cy.viewport(1440, 900) and cy.viewport(375, 667) with visibility assertions -> Option A
  4. Quick Check:

    Separate viewport tests cover all breakpoints [OK]
Hint: Test each breakpoint separately for reliable responsive checks [OK]
Common Mistakes:
  • Assuming one viewport size covers all devices
  • Ignoring desktop or mobile viewport testing
  • Relying on default viewport without changes
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard