e2e
End-to-End Tests (Cypress)
Detection
Run in parallel:
- Check
package.jsonforcypressversion - Read
cypress.config.tsfor baseUrl and test file patterns - Read 1-2 existing test files in
cypress/e2e/to match conventions
Workflow
- Read existing tests and config to match project style
- Understand the user flow — ask if unclear
- Identify selectors (see selectors.md)
- Write tests in
cypress/e2e/— one file per flow or feature
Format
describe('login flow', () => {
beforeEach(() => {
cy.visit('/login')
})
it('logs in with valid credentials', () => {
cy.findByLabelText('Email').type('user@example.com')
cy.findByLabelText('Password').type('password')
cy.findByRole('button', { name: 'Sign in' }).click()
cy.url().should('include', '/dashboard')
cy.findByRole('heading', { name: 'Dashboard' }).should('be.visible')
})
it('shows error with invalid credentials', () => {
cy.findByLabelText('Email').type('wrong@example.com')
cy.findByLabelText('Password').type('wrong')
cy.findByRole('button', { name: 'Sign in' }).click()
cy.findByRole('alert').should('contain.text', 'Invalid credentials')
})
})
Selector priority
Prefer @testing-library/cypress commands when installed:
cy.findByRole('button', { name: 'Submit' })— bestcy.findByLabelText('Email')— formscy.findByText('Welcome')— text contentcy.get('[data-testid="submit"]')— last resort
See selectors.md for full guide.
Rules
- Use
@testing-library/cypressselectors when available, elsecy.get - Use
data-testidonly as last resort - One logical outcome per
itblock - Test behavior, not implementation details
- Never use
cy.wait(<number>)— usecy.findBy*auto-retry instead
Error Handling
- If
cypressis not inpackage.json→ stop and ask user to install Cypress first - If
cypress.config.tsis missing → ask user to runnpx cypress opento initialize config - If
baseUrlis unreachable → verify the dev server is running before writing tests that require it
More from helderberto/skills
explain-code
Explains code with visual diagrams and analogies. Use when explaining how code works, teaching about a codebase, or when the user asks "how does this work?" Don't use for modifying code, fixing bugs, or generating new implementations.
45ship
Commit and push changes using atomic commits. Use when user asks to "ship", "commit and push", or requests committing and pushing changes. Don't use for creating pull requests or reviewing changes before committing.
45refactor-plan
Create structured refactoring plans. Use when user wants to plan a refactor, needs a refactoring strategy, or mentions breaking down large changes into small commits. Don't use for implementing code changes directly, small one-line fixes, or renaming a single variable.
44safe-repo
Check for sensitive data in repository. Use when user asks to "check for sensitive data", "/safe-repo", or wants to verify no company/credential data is in the repository. Don't use for general code review, adding .gitignore entries, or scanning non-git directories.
41lint
Run linting and formatting checks. Use when user asks to "run linter", "/lint", "check linting", "fix lint errors", or requests code linting/formatting. Don't use for running tests, type-checking only, or projects without a lint script in package.json.
40tdd
Guides test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants test-first development, or requests TDD workflow. Don't use for writing tests after implementation, adding tests to existing untested code, or one-off test fixes.
40