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 browser

View on GitHub (pinned to 0d85fdc912)

Solutions

  1. Complete onboarding for the target testing type: run `cypress open`, choose Component/E2E Testing, and let Cypress scaffold the config block.
  2. Manually add the missing e2e {} or component {} configuration block to cypress.config.{js,ts} (including componentNameAndFilePathFunc/bundler settings for CT as needed).
  3. Verify isTestingTypeConfigured returns true for the target type before calling runSpec (the launchpad should show the type as set up).
  4. 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

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


AI-assisted analysis of cypress-io/cypress@0d85fdc912 (2026-08-12). Data as JSON: /api/errors/72f6ef4b539543dd. Report an issue: GitHub.