nodejs / nodejs/node

test_runner: `--watch` with `--test-isolation=none` reruns every test file, not the affected one

未关闭
#65,037 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

主要语言
JavaScript
星标
122k
派生
37.4k
平均合并
4 天 3 小时
30 天内合并 PR
272

描述

Version

v26.5.0

Platform
Darwin 25.5.0 arm64

(Not platform-specific — it falls out of lib/internal/test_runner/runner.js.)

Subsystem

test_runner

What steps will reproduce the bug?

Two test files; edit only the first and see which ones re-run.

mkdir -p /tmp/probe && cd /tmp/probe
printf 'const {test}=require("node:test");\ntest("A-ran",()=>{});\n' > a.test.js
printf 'const {test}=require("node:test");\ntest("B-ran",()=>{});\n' > b.test.js

# Run once with, once without --test-isolation=none.
# After the first run settles, append a comment to a.test.js and watch the output.
node --test --watch a.test.js b.test.js
node --test --test-isolation=none --watch a.test.js b.test.js

Output produced after touching a.test.js only:

=== default isolation ('process') ===
✔ A-ran (1.202958ms)
ℹ tests 1

=== --test-isolation=none ===
✔ A-ran (0.673791ms)
✔ B-ran (0.116333ms)
ℹ tests 2
How often does it reproduce? Is there a required condition?

Every time. The required condition is --watch together with --test-isolation=none
(equivalently run({ watch: true, isolation: 'none' })).

What is the expected behavior? Why is that the expected behavior?

Only a.test.js re-runs. That is what the documentation promises, without an
isolation caveat — Watch mode:

In watch mode, the test runner will watch for changes to test files and their
dependencies. When a change is detected, the test runner will rerun the tests
affected by the change.

The isolation option's own docs describe it purely as where tests run ("all
test files run in the current process"), so nothing signals that it also changes
which files a change re-runs.

What do you see instead?

Every test file in the run re-runs on every change.

The two modes take different branches in watchFiles' 'changed' handler
(lib/internal/test_runner/runner.js#L659-L672):

if (opts.isolation === 'none') {
  PromisePrototypeThen(restartTestFile(kIsolatedProcessName), undefined, (error) => {
    triggerUncaughtException(error, true /* fromPromise */);
  });
} else {
  watcher.unfilterFilesOwnedBy(owners);
  PromisePrototypeThen(SafePromiseAllReturnVoid(testFiles, async (file) => {
    if (!owners.has(file)) {
      return;
    }
    await restartTestFile(file);
  }, ...));
}

kIsolatedProcessName is the sentinel for the single child that runs the whole
file list, set up in run() under the matching isolation === 'none' && watch
branch — so owners (the set of files the change actually affects) is computed
and then discarded.

Additional information

This looks fixable rather than inherent. The isolation: 'none' watch path
still spawns a fresh child process per change, so there is no ESM
module-cache obstacle to re-running a subset — the child could be given
owners instead of the full testFiles.

The obvious counter-argument, and the reason this might be deliberate: under isolation: 'none' files share a process and can therefore share module-level state, so a subset run is not always equivalent to the full run. Although that probably indicates an unintended coupling between test suites! If that is the rationale, it would be worth stating in the docs — as written they promise the incremental behavior unconditionally.

The practical cost is that --test-isolation=none and --watch pull in opposite directions. Isolation none exists to amortize an expensive import graph across many files, which pays off for a whole-suite run. Watch mode's value is that a save costs one file. Combining them gives you neither: in a suite where the shared import cost is what motivated isolation: 'none' in the first place (ours is ~575 files behind a large DI container), every keystroke-save re-runs everything.

Happy to open a PR for whichever direction maintainers prefer (scope the child to owners, or document the difference). I've opened a docs-only PR for the second in the meantime.

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

调研方向

从 lib/internal/test_runner/runner.js 开始,重点查看第 659-672 行附近的 watchFiles 'changed' 处理器,以及 run() 中 isolation-none 的 watch 设置。使用报告中的双文件命令重现问题,然后追踪 owners 和 testFiles 如何传递给新的子进程。完成的标准是实现预期的受影响文件行为,或者明确解决文档所述的 isolation 行为,并由测试覆盖。

由索引模型根据 Issue 内容生成。

评估

技术栈
javascript
领域
testing
Issue 类型
缺陷
难度
4/5
预计耗时
3-5 天
活跃度
冷清
描述清晰度
基本清楚
新手友好度
45/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。