Q5 of 48 · Cypress
What file structure does a typical Cypress project have?
Short answer
Short answer: `cypress.config.ts` at the root, plus a `cypress/` folder with subfolders `e2e/` (specs), `fixtures/` (test data), `support/` (custom commands and hooks), and `downloads/` / `screenshots/` / `videos/` (artifacts). Component testing adds a `component/` folder.
Detail
A fresh Cypress 13+ install creates this layout. The cypress.config.ts (or .js) at the project root is the single source of truth for configuration: base URL, viewport, timeouts, retries, environment variables, and the e2e/component test setup blocks.
Inside cypress/:
e2e/— your specs, conventionally named*.cy.ts. Organise by feature or user journey rather than by page.fixtures/— JSON or other static test data loaded withcy.fixture().support/— runs before every spec.commands.tsregisters custom commands;e2e.tsis auto-loaded for global hooks (uncaught error handlers, before/after wiring).downloads/,screenshots/,videos/— generated artifacts. Should be gitignored.
For component testing, a parallel component/ folder appears with the same conventions but for component specs (*.cy.tsx typically). The component/ and e2e/ blocks in the config can have entirely different specs, support files, and viewport defaults.
The convention *.cy.ts (instead of *.spec.ts) keeps Cypress specs distinct from unit tests in monorepos that share Jest/Vitest tooling.
// EXAMPLE
tree.sh
qa-codes/
├── cypress.config.ts
├── cypress/
│ ├── e2e/
│ │ ├── auth/
│ │ │ └── login.cy.ts
│ │ └── checkout/
│ │ └── place-order.cy.ts
│ ├── fixtures/
│ │ ├── users.json
│ │ └── products.json
│ ├── support/
│ │ ├── commands.ts # custom commands
│ │ ├── e2e.ts # global hooks, error handlers
│ │ └── component.ts
│ ├── component/
│ │ └── Button.cy.tsx
│ ├── downloads/ # gitignored
│ ├── screenshots/ # gitignored
│ └── videos/ # gitignored
└── tsconfig.json