cypress/ ├── e2e/ # End-to-end test files │ ├── login.cy.js # Example test for login │ └── dashboard.cy.js # Example test for dashboard ├── fixtures/ # Test data files (JSON, etc.) │ └── users.json # Sample user data ├── support/ # Support files and custom commands │ ├── commands.js # Custom Cypress commands │ ├── e2e.js # Global setup for tests │ └── index.js # Entry point for support ├── videos/ # Automatically saved test run videos └── screenshots/ # Automatically saved screenshots on failure cypress.config.js # Main Cypress configuration file package.json # Project dependencies and scripts
Cypress folder structure - Framework Patterns
- Test Layer (cypress/e2e): Contains the actual test scripts that simulate user actions and verify app behavior.
- Support Layer (cypress/support): Holds reusable code like custom commands and global hooks to keep tests clean and DRY.
- Fixtures Layer (cypress/fixtures): Stores static test data files used to feed tests with consistent inputs.
- Configuration Layer (cypress.config.js): Defines environment settings, base URLs, browser options, and other global settings.
- Output Layer (videos/screenshots): Automatically generated test run artifacts for debugging and reporting.
Use cypress.config.js to manage settings like base URL, test retries, and viewport size.
Define environment variables inside cypress.config.js or via CLI to handle different environments (dev, staging, prod).
Example snippet to set base URL and environment variables:
export default defineConfig({
e2e: {
baseUrl: 'https://example.com',
env: {
username: 'testuser',
password: 'securePass123'
},
retries: 2,
viewportWidth: 1280,
viewportHeight: 720
}
})
Use Cypress.env() in tests to access these variables securely.
Integrate Cypress with CI/CD pipelines (GitHub Actions, Jenkins, GitLab CI) to run tests automatically on code changes.
Use built-in reporters or plugins like mochawesome for detailed HTML and JSON reports.
Configure video and screenshot capture on test failures to help diagnose issues quickly.
Example GitHub Actions step to run Cypress tests:
- name: Run Cypress Tests
uses: cypress-io/github-action@v5
with:
browser: chrome
headless: true
- Keep tests independent: Each test should run alone without relying on others.
- Use custom commands: Put repeated actions in
cypress/support/commands.jsto avoid duplication. - Organize tests by feature: Group related tests in folders inside
cypress/e2efor clarity. - Use fixtures for test data: Load data from
cypress/fixturesto keep tests clean and maintainable. - Configure retries and timeouts: Handle flaky tests gracefully with retries and proper waits.
Question: 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 reuse it across all tests.
Practice
Solution
Step 1: Understand folder purposes
Thee2efolder is designed to hold end-to-end test files in Cypress.Step 2: Differentiate from other folders
fixturesholds test data,supporthas helper code, andpluginsmanages plugins, not tests.Final Answer:
e2e-> Option DQuick Check:
Tests go ine2efolder [OK]
e2e folder by default [OK]- Confusing
fixtureswith test files - Thinking
supportholds tests - Assuming
pluginsstores tests
Solution
Step 1: Recall default Cypress folder structure
Fixture files are stored directly inside thecypress/fixturesfolder.Step 2: Eliminate incorrect paths
Options placing fixtures insidesupportore2eare incorrect. Also,fixtures/cypressis not standard.Final Answer:
cypress/fixtures -> Option AQuick Check:
Fixtures folder iscypress/fixtures[OK]
cypress/fixtures [OK]- Placing fixtures inside
support - Adding extra nested folders incorrectly
- Confusing fixtures with test files location
cypress/
e2e/
fixtures/
support/
commands.js
index.jsSolution
Step 1: Identify default support file
Cypress automatically loadscypress/support/index.jsas the support file.Step 2: Differentiate from other files
commands.jsis imported insideindex.js, but Cypress looks forindex.jsby default.Final Answer:
cypress/support/index.js -> Option BQuick Check:
Support file =cypress/support/index.js[OK]
support/index.js by default [OK]- Choosing commands.js as main support file
- Looking in e2e or fixtures folders for support
- Assuming support file is optional
cypress/support instead of cypress/e2e. What issue will you face?Solution
Step 1: Understand folder roles
Thesupportfolder is for helper code, not test files.Step 2: Consequence of wrong placement
Cypress only runs tests insidee2efolder by default, so tests insupportwon't run.Final Answer:
Tests will not run because Cypress does not look for tests insupport-> Option AQuick Check:
Tests must be ine2e, notsupport[OK]
e2e folder won't run [OK]- Assuming tests run anywhere inside cypress folder
- Confusing support folder as test location
- Thinking fixtures affect test execution location
Solution
Step 1: Identify fixture folder purpose
Thecypress/fixturesfolder is meant for test data files, including environment-specific data.Step 2: Organize environment data properly
Using subfolders likedevandprodinsidefixtureskeeps data organized and easy to load.Final Answer:
Place all environment files insidecypress/fixtureswith subfolders likedev,prod-> Option CQuick Check:
Environment data belongs infixtureswith subfolders [OK]
fixtures for environment data [OK]- Putting data in
supportfolder - Mixing data files with test files in
e2e - Creating folders outside Cypress structure
Ready to prove it?
Pass the test and this pattern moves unknown
