test_runner: support mock file system

[axetroy]

What is the problem this feature will solve?

The current test requires writing files to a real disk when reading and writing files related to the file system, which is very unsafe.

After all, the file may remain due to test case failure and other reasons.

What is the feature you are proposing to solve the problem?

Under the mock namespace, APIs are exposed to provide a mock file system.

mock.fileSystem.enable({ });

And provide some options

e.g.

Override the file that defined by defaults

mock.fileSystem.enable({
  files: {
    '/path/to/file': new Uint8Array([0])
  }
});

// it will read the virtual file system first if it does exist
// if not found, then read the read the real file system
fs.readFileSync('/path/to/file')

Override the whole file system

mock.fileSystem.enable({
  files: {
    '/path/to/file': new Uint8Array([0])
  },
  override: true // override the whole file system
});

// This file is exists in the real file system
// But not define in the vitual file system, so it should throw an error
fs.readFileSync('/etc/proc')

What alternatives have you considered?

mock-fs

[cjihrig]

It seems unlikely that anyone will pick this up since it has been open for nearly 5 months with no interactions. I think this would be a neat feature, but I'm not sure if it belongs in core (or if it does, it may be a better fit for fs than the test runner).

[github-actions]

There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the never-stale Issues and PRs exempt from automated stale handling. label or close this issue if it should be closed. If not, the issue will be automatically closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.

[axetroy]

bump

[sozua]

Bringing back this discussion, @cjihrig. I'd like to try helping on this, but wanted to clarify some things first.

1: On whether this belongs in the test runner or fs: the test runner already owns mock.timers and module mocking. Would mock.fs fit that pattern, or is there a reason to keep it closer to the fs subsystem?

2: The fs API surface is large, so full coverage isn't very practical for a first pass. A starting point could be basic file I/O and directory operations. Enough to let tests define virtual files and avoid writing to disk. Unmocked paths could fall back to real fs, or throw if the user wants full isolation.

Does that seem like a reasonable scope, or should the first iteration be narrower/broader?

[cjihrig]

@sozua I'm going to ping @nodejs/test_runner about your comment above ^. I personally don't have an opinion on it.

[MoLow]

Id add it as mock.fs, and mark it as experimental, to allow it to be gradually implemented

[ljharb]

I would suggest keeping it behind a flag - not just marked as experimental (which is largely useless, because if it gets sufficient adoption it can't be removed anyways) - until it has full API coverage.