test_runner: add mock file system API

[mcollina]

Add t.mock.fs(): an in-memory mock file system for the test runner, backed by a mounted VirtualFileSystem.

The mock is mounted at a reserved mount point (${os.devNull}/vfs/<n>) assigned when it is created and exposed as mockFs.mountPoint, so it never shadows real files or directories. Files are accessible through the regular node:fs APIs and can be loaded with require() and import via the module loader integration.

test('reads configuration from a mock file', (t) => {
  const mockFs = t.mock.fs({
    files: {
      'config.json': JSON.stringify({ debug: true }),
    },
  });

  const config = JSON.parse(
    fs.readFileSync(path.join(mockFs.mountPoint, 'config.json'), 'utf8'));

  // addFile() returns the absolute path of the new file.
  const modPath = mockFs.addFile('mod.js', 'module.exports = 42;');
  assert.strictEqual(require(modPath), 42);
});

The returned MockFSContext exposes mountPoint, vfs, addFile(), addDirectory(), existsSync(), and restore(). Because mount points are assigned rather than chosen, addFile()/addDirectory() return the absolute path of what they created. The mock is unmounted automatically when the associated test finishes, like the other MockTracker APIs.

This adapts the mock fs concept originally proposed for the shadowing VFS design (where a prefix option mounted over real paths) to the non-shadowing implementation that landed in #63653.

🤖 Generated with Claude Code

https://claude.ai/code/session_01BuuR21ULqZEHoFmqWCnoyx

[nodejs-github-bot]

Review requested:

• @nodejs/test_runner

[benjamingr]

I don't understand why we'd want/need these separate APIs (like existsSync/addRirectory etc) the user can just call mockFs.vfs.mkdirSync can't they?

[benjamingr]

For restore to make sense here IMO the vfs would need to actually "take over" something like other mocks. I don't understand when I'd ever do this.

OTOH if mockFs could intercept/take over calls (i.e. like mock.module) it would make sense.

This is cool but I don't understand why I'd use this over mock.module("node:fs", { exports: new VirtualFileSystem() })

[benjamingr]

I'm approving since the code itself looks fine and this is tagged early development and iteration is fine - but I'm not convinced this has a benefit over mock.module + VirtualFileSystem and I'm wary of adding more ways to e.g. create a file or directory since the current ones work with VirtualFileSystem as is

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.13%. Comparing base (7551e1d) to head (1462eb5).
⚠️ Report is 15 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #65798      +/-   ##
==========================================
+ Coverage   90.05%   90.13%   +0.08%     
==========================================
  Files         769      769              
  Lines      261396   261765     +369     
  Branches    49631    49690      +59     
==========================================
+ Hits       235399   235946     +547     
+ Misses      17034    16852     -182     
- Partials     8963     8967       +4     

Files with missing lines	Coverage Δ
lib/internal/test_runner/mock/mock.js	97.62% <100.00%> (+0.29%)	⬆️

... and 63 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.