Cypress support

Detection#

Test Chronicle detects Cypress through cypress.config.ts, cypress.config.js, cypress.json, package dependencies, and conventional test locations. Where available, the configured specPattern helps identify the relevant files.

For default Cypress projects this usually means specs under cypress/e2e, cypress/integration, or the configured support structure. In a workspace with both Cypress and component tests, test discovery settings can narrow the scan without disabling other frameworks in the same repository.

Parsed information#

Test Chronicle records test names, file paths, describe groups, line numbers, and common forEach parameterised patterns. Cypress tags are not currently recorded as a supported metadata field.

The parser focuses on definitions that are visible in source: describe, context, it, and specify style tests. It records enough structure to answer where a Cypress test lives, how it is grouped, and how that definition changed over time.

Limits and configuration#

Cypress runtime retries, browser choices, and generated dashboard runs are not expanded into separate source tests. Parameterised loops are tracked as patterns when they can be identified statically, which keeps counts aligned with the definitions committed to Git.

If Cypress fixtures, generated files, or archived specs are being detected as active tests, add an exclusion or framework directory override in project settings. For custom layouts, keep the Cypress scope as narrow as the repository allows.

History views#

After parsing, test changes are mapped to Git commits and appear in the same timeline, test, file, contributor, and trend views used by other frameworks.

For repositories with a custom Cypress layout, set an explicit Cypress directory in the Test Chronicle project settings.

This helps teams distinguish current Cypress coverage from Cypress history. A release review can show which end-to-end tests were added, renamed, deleted, or maintained during the same period as product code changes.