Implementing Test Doubles for File System Access

In this lesson, you will learn how to replace slow, volatile disk-based file operations with high-speed, deterministic in-memory filesystems to streamline your unit testing suite.

The Problem with Real Disk I/O

When unit testing logic that interacts with the file system (e.g., fs.promises.readFile), relying on the actual disk introduces several anti-patterns: tests become slow due to physical I/O latency, they risk leaving behind "junk" files if a test crashes, and they are susceptible to environmental interference (like insufficient permissions or disk space).

Using Memory-Backed Doubles

To isolate your code, we replace the fs module with an in-memory double—a virtual representation of a filesystem that lives entirely in RAM. Instead of creating physical files, your code reads from and writes to a JavaScript object or a library specifically designed to emulate Node.js fs behavior, such as memfs.

By injecting this double via dependency injection (as we discussed in earlier lessons), your business logic remains oblivious to whether the data comes from a spinning drive or a memory buffer.

Conceptual Implementation

Rather than importing fs directly in your production code, pass it as a dependency to your service:

// production code
async function saveUserConfig(config, fileSystem = require('fs').promises) {
  await fileSystem.writeFile('/data/config.json', JSON.stringify(config));
}

// test code
const { createFsFromVolume, Volume } = require('memfs');

test('should write config to memory', async () => {
  const vol = new Volume();
  const memoryFs = createFsFromVolume(vol).promises;
  
  await saveUserConfig({ theme: 'dark' }, memoryFs);
  
  const result = await memoryFs.readFile('/data/config.json', 'utf-8');
  expect(JSON.parse(result).theme).toBe('dark');
});

This approach allows your tests to run in isolation. Because the memory volume is reset for every test case, you gain complete control over the filesystem state without the overhead of cleanup scripts or disk cleanup logic. You aren't just testing that the code works; you are testing it against a predictable, ephemeral environment that guarantees no side effects leak between runs.

Key Takeaway: By substituting real disk operations with in-memory filesystems, you transform fragile, slow I/O tests into lightning-fast, deterministic unit tests that are perfectly isolated from the host environment.