Allow tests to pass without any test files (e.g. via Vitest passWithNoTests) #33055

Command

test

Description

Executing the test command on a project (app or lib) that does not have any test files (yet) will always lead to the following error message:

An exception occurred while getting runner-specific build options:
Error: No tests found matching the following patterns:
- Included: **/*.spec.ts, **/*.test.ts

Please check the 'test' target configuration in your project's 'angular.json' file.

However, many use cases exist where this behaviour is unintended. For example, a freshly generated project (even more so in a monorepo) will often start out without any real test cases defined, and it even may take some time for the first ones to be written. Even at this early point, though, I (as a developer) will usually want to already integrate test execution into a quality gate setup (like continuous integration).

Currently, the Angular CLI does not offer a way to allow the test command to succeed when no test files exist.

Related issue: nrwl/nx#34241

Describe the solution you'd like

The most pragmatic solution would probably be:

• Remove the custom Angular CLI check for test files, see:

  angular-cli/packages/angular/build/src/builders/unit-test/runners/vitest/build-options.ts

  Lines 161 to 170 in 5adc925

  	// Find test files
  	const testFiles = await findTests(include, exclude, workspaceRoot, projectSourceRoot);
  	if (testFiles.length === 0) {
  	throw new Error(
  	'No tests found matching the following patterns:\n' +
  	`- Included: ${include.join(', ')}\n` +
  	(exclude.length ? `- Excluded: ${exclude.join(', ')}\n` : '') +
  	`\nPlease check the 'test' target configuration in your project's 'angular.json' file.`,
  	);
  	}

• Instead, rely on Vitest and its passWithNoTests option - which is false by default, so no breaking change is to be expected (besides a different log message)

Describe alternatives you've considered

Alternatively:

• The Angular CLI test command could also expose its own option. This would however collide with the respective Vitest option and thus require conflict resolution / priority checks. Plus, skimming the source code leads me to believe that the Angular CLI is currently not actively loading any custom Vite config, just passing it on - so changes here would presumably affect multiple places.