| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
…watch mode When non-test files (services, components, etc.) change during watch mode, use Vitest's module graph to find dependent test specifications and include them in the re-run set. Previously only direct .spec.ts file changes triggered test re-runs. Consolidates the file processing into a single loop for clarity. Fixes angular#32159
There was a problem hiding this comment.
This pull request enhances the Vitest test runner to ensure that changes to non-test files, such as components or services, correctly trigger test reruns in watch mode. The implementation now utilizes Vitest's module graph to identify and queue dependent test specifications when an output file is modified. Additionally, a new behavior test has been added to verify that modifying a component file results in the expected test execution and results. I have no feedback to provide as there were no review comments to evaluate.
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
PR Checklist
PR Type
What is the current behavior?
In watch mode, the unit-test builder only re-runs tests when .spec.ts files change. Changes to non-test files (services, components, etc.) are ignored because entryPointToTestFile only maps test files, and getModuleSpecifications() is never called for unmapped files.
Issue Number: #32159
What is the new behavior?
When non-test files change during watch mode, vitest.getModuleSpecifications() is called on the absolute output file path. Vitest's module graph traverses backwards to find all dependent test specifications, which are then included in the re-run set.
The file processing has been consolidated into a single loop for clarity — test files are mapped via entryPointToTestFile, non-test files query Vitest's module graph directly.
Does this PR introduce a breaking change?