Coverage in library unit-test includes dependent library files and does not reduce runtime when using coverage.include #33484

Activity

1. angular-robot

   added

   area: @angular/build

   gemini-triagedLabel noting that an issue has been triaged by geminiLabel noting that an issue has been triaged by gemini

   on Jun 30, 2026
2. angular-robot

   added this to the needsTriage milestone on Jun 30, 2026
3. Carlosamouco

   changed the title [-]`unit-test` performance degradation when enabling coverage for angular libraries[/-] [+]Coverage in library `unit-test` includes dependent library files and does not reduce runtime when using coverage.include[/+] on Jun 30, 2026
4. hawkgs

   added

   angular/build:unit-test

   and removed

   gemini-triagedLabel noting that an issue has been triaged by geminiLabel noting that an issue has been triaged by gemini

   on Jul 1, 2026
5. nagahara-naoki commented on Nov 8, 2026

   

   nagahara-naoki

   on Nov 8, 2026

   More actions

   Thanks for reporting this! I tried a small two-library example and could reproduce the report-scope behavior with Angular CLI / @angular/build 22.0.4 and Vitest / @vitest/coverage-v8 4.1.9 (Node 24.22.2, macOS arm64, jsdom).

   What I checked

   1. Generate lib-a and lib-b using the Angular CLI library schematic.
   2. Build lib-b with ng build lib-b --configuration development, keeping the generated lib-b path mapping to dist/lib-b.
   3. Import LibB from lib-b in the LibA component and render it in the template:

   import { Component } from '@angular/core';
   import { LibB } from 'lib-b';
   
   @Component({
     selector: 'lib-lib-a',
     imports: [LibB],
     template: '<lib-lib-b />',
   })
   export class LibA {}

   4. Run only the generated lib-a test:

   ng test lib-a --watch=false --coverage --coverage-reporters=json

   The single lib-a test passes, but coverage/lib-a/coverage-final.json contains both:

   projects/lib-a/src/lib/lib-a.ts
   projects/lib-b/src/lib/lib-b.ts
   

   Explicitly restricting the coverage scope excludes lib-b:

   ng test lib-a --watch=false --coverage --coverage-reporters=json \
     --coverage-include='projects/lib-a/src/**/*.ts'

   I have not reproduced the substantial slowdown in this small example. Three runs per configuration took roughly two seconds each, with no clear improvement from restricting coverage. This is only a small smoke comparison, not a performance benchmark. I also have not yet checked the latest release or repository main.

   Question about the intended behavior

   Is the default coverage scope for a library expected to include executed code from dependent workspace libraries, or should it be limited to the library being tested? Since lib-b is executed by the test, I wanted to clarify whether this is intended behavior before proposing a change.

   If the intended default is project-local coverage, one possible direction would be to derive the default include pattern from the tested project's sourceRoot, while preserving explicit coverageInclude / runner configuration overrides. That would address the report scope; the performance concern would still need separate investigation.