cypress-io/cypress · error · RunSpecError
TESTING_TYPE_NOT_CONFIGURED
TESTING_TYPE_NOT_CONFIGURED
Error message
Input path matched specPattern for '${targetTestingType}' testing type, but it is not configured. What it means
Thrown by ProjectActions.runSpec (ProjectActions.ts:554-557) with code TESTING_TYPE_NOT_CONFIGURED when the resolved targetTestingType differs from the current one AND lifecycleManager.isTestingTypeConfigured(targetTestingType) returns false. 'Configured' means the corresponding e2e or component block exists/is set up in cypress.config and onboarding for that type was completed. So the file matches the pattern (e.g. a component glob) but that testing type was never set up, blocking an automatic switch. Returned as { code: 'TESTING_TYPE_NOT_CONFIGURED', detailMessage }.
Source
Thrown at packages/data-context/src/actions/ProjectActions.ts:556
} else {
throw new RunSpecError('NO_SPEC_PATTERN_MATCH', 'Unable to determine testing type, spec does not match any configured specPattern')
}
debug(`Spec %s matches '${targetTestingType}' pattern`, specPath)
debug('Attempting to launch spec %s', specPath)
// Look to see if there's actually a file at the target location
// This helps us avoid switching testingType *then* finding out the spec doesn't exist
if (!this.ctx.fs.existsSync(specPath)) {
throw new RunSpecError('SPEC_NOT_FOUND', `No file exists at path ${specPath}`)
}
// We now know what testingType we need to be in - if we're already there, great
// If not, verify that type is configured then switch (or throw an error if not configured)
if (this.ctx.coreData.currentTestingType !== targetTestingType) {
if (!this.ctx.lifecycleManager.isTestingTypeConfigured(targetTestingType)) {
throw new RunSpecError('TESTING_TYPE_NOT_CONFIGURED', `Input path matched specPattern for '${targetTestingType}' testing type, but it is not configured.`)
}
debug('Setting testing type to %s', targetTestingType)
const specChangeSubscription = this.ctx.emitter.subscribeTo('specsChange', { sendInitial: false })
const originalTestingType = this.ctx.coreData.currentTestingType
// Temporarily toggle testing type so the `activeBrowser` can be initialized
// for the targeted testing type. Browser has to be initialized prior to our "relaunch"
// call below - this can be an issue when Cypress is still on the launchpad and no
// browser has been launched yet
this.ctx.lifecycleManager.setCurrentTestingType(targetTestingType)
await this.ctx.lifecycleManager.setInitialActiveBrowser()
this.ctx.lifecycleManager.setCurrentTestingType(originalTestingType)
// This is the magic sauce - we now have a browser selected, so this will toggle
// the testing type, trigger specs to update, and launch the browserView on GitHub (pinned to 0d85fdc912)
Solutions
- Complete onboarding for the target testing type: run `cypress open`, choose Component/E2E Testing, and let Cypress scaffold the config block.
- Manually add the missing e2e {} or component {} configuration block to cypress.config.{js,ts} (including componentNameAndFilePathFunc/bundler settings for CT as needed).
- Verify isTestingTypeConfigured returns true for the target type before calling runSpec (the launchpad should show the type as set up).
- If you did not intend to run that testing type, check the specPattern — the file may be matching the wrong glob.
Example fix
// before (cypress.config.ts) — only e2e configured, running a component spec
// export default defineConfig({ e2e: { ... } })
// after — add the component block and onboard
// export default defineConfig({
// e2e: { ... },
// component: { specPattern: 'src/**/*.cy.{js,ts,jsx,tsx}', devServerConfig: { ... } }
// }) Defensive patterns
Strategy: validation
Validate before calling
// Confirm the target testing type is configured before runSpec
const targetTestingType: TestingType = /* derived from specPattern match */
if (
ctx.coreData.currentTestingType !== targetTestingType &&
!ctx.lifecycleManager.isTestingTypeConfigured(targetTestingType)
) {
// prompt the user to onboard that testing type; do not call runSpec yet
return
}
await ctx.actions.runSpec({ specPath }) Prevention
- Complete onboarding for each testing type you intend to run (e2e and component) via `cypress open`.
- Ensure cypress.config defines both e2e {} and component {} blocks when mixing spec types.
- Surface the 'testing type not configured' state in the launchpad so users onboard before running.
When it happens
Trigger: Running a spec whose pattern maps to a testing type that is not configured — most commonly a component spec when only e2e was onboarded, or an e2e spec when only component testing was set up. The runSpec switch-and-relaunch path requires the target type to be configured first.
Common situations: User completed onboarding only for e2e, then tries to run a file that matches the component specPattern (or vice versa); a cypress.config that defines specPattern for a type but no top-level e2e/component configuration block; partial/failed onboarding; switching projects where the other testing type was never initialized.
Related errors
- NO_SPEC_PATTERN_MATCH
- Could not find a project with projectType "application" in "
- Your Cypress devServer config is missing a required webpackC
- Invalid grep burn value: ${grepBurn}
- cy.visit from a component spec is not allowed
AI-assisted analysis of cypress-io/cypress@0d85fdc912 (2026-08-12).
Data as JSON: /api/errors/72f6ef4b539543dd.
Report an issue: GitHub.