opal-frontend-cypress-component
Cypress component testing guidance for opal-frontend. Use when adding or updating component specs, configuring component test setup, or choosing selectors, mocks, and POM Actions or Flows.
When & Why to Use This Skill
This Claude skill provides comprehensive, project-specific guidance for Cypress component testing within the opal-frontend architecture. It streamlines the development of high-quality test suites by enforcing best practices for component setup, Page Object Model (POM) integration, stable selector management, and API mocking, ensuring reliable and maintainable frontend automation.
Use Cases
- Creating or updating Cypress component specs: Standardize the structure and grouping of test files based on project capabilities like account creation or enquiry.
- Configuring component test setups: Utilize shared router-outlet patterns to efficiently register routes, provide services, and intercept APIs for isolated testing.
- Implementing Page Object Model (POM) workflows: Replace direct 'cy.get' calls with reusable Actions and Flows to improve test readability and reduce maintenance overhead.
- Managing API intercepts and fixtures: Isolate test scenarios by organizing API mock data and intercept helpers within spec-specific directories.
- Synchronizing selectors and hooks: Ensure test stability by using centralized locator modules and adding semantic data attributes to application code for better testability.
| name | opal-frontend-cypress-component |
|---|---|
| description | Cypress component testing guidance for opal-frontend. Use when adding or updating component specs, configuring component test setup, or choosing selectors, mocks, and POM Actions or Flows. |
Opal Frontend Cypress Component Testing
Overview
Use these rules when writing or updating Cypress component specs in opal-frontend.
Structure and Setup
- Component specs live in
cypress/component/**and are grouped by capability (for example,manualAccountCreation,fineAccountEnquiry, sharedpages/). - Prefer the shared router-outlet setup in
cypress/component/fineAccountEnquiry/accountEnquiry/setupso specs can register routes, provide shared services, intercept APIs, and navigate to the component under test. - Extend the shared setup rather than creating a new mount helper, unless it causes regressions.
Page Object Model Usage
- Do not call
cy.getdirectly when a POM exists. - Import Actions or Flows from
cypress/e2e/functional/opal/actions/**orcypress/e2e/functional/opal/flows/**and use their methods against the mounted component.
Selectors and Hooks
- Use stable selectors from
cypress/shared/common.locators.tsandcypress/shared/selectors/**. - If a component lacks a hook, add a semantic ID or data attribute in
src/appfirst, then expose it via the selector modules so component and E2E tests stay in sync.
Mocks, Intercepts, and Tags
- Store API intercept fixtures beside each spec in
<spec-folder>/mocks/**. - Copy or extend existing mock files so scenarios stay isolated.
- Use local intercept helpers in
<spec-folder>/intercept/**with the router-outlet setup. - Tag tests with Jira IDs when scoping to acceptance criteria (example:
{ tags: ['@PO-604'] }).
Running a Spec
- Run a single component spec with:
yarn cypress run --browser chrome --component --spec 'cypress/component/fineAccountEnquiry/accountEnquiry/AccountEnquiry.cy.ts'
Handling Real Product Bugs
- If a component spec fails due to a real product bug, do not change application code to force a pass.
- Skip or mark the test pending and explain the failure in the task update.