Jest测试中避免全局mock污染，仅为指定Express控制器mock fs.existsSync的方法

你当前手动赋值替换fs.existsSync的实现，本质是修改Node.js进程内全局单例的fs对象属性，存在两个核心问题：一是如果测试执行中抛出异常，写在测试末尾的恢复代码会直接被跳过，造成后续同环境下所有fs.existsSync调用逻辑被篡改；二是无差别替换会让同测试上下文中其他模块的正常fs判断逻辑全部被影响，直接引发测试失败。
下面是两种经过社区验证的规范实现，可根据隔离需求选择：

方案1：通过jest.spyOn绑定单测试用例生命周期（通用首选） #

Jest内置的spy方法自带完整的上下文还原能力，哪怕测试中途报错，也会自动把fs的原方法还原，完全不需要手动编写存引用、赋值、恢复的样板代码。
实际测试写法参考：

import fs from 'fs'
import request from 'supertest'
import app from '../app'

it('模板不存在时返回500服务错误', async () => {
  // 用spyOn包裹fs.existsSync，保留原方法引用
  const existsSyncSpy = jest.spyOn(fs, 'existsSync')
    // 只针对目标模板路径返回mock值，其他路径走原生逻辑
    .mockImplementation((targetPath) => {
      // 匹配控制器里用到的具体模板路径
      if (targetPath === '/abs/path/to/your/email-template.html') {
        return false
      }
      // 其余所有路径的判断全部走原生fs逻辑，完全不影响其他模块的正常调用
      return Object.getPrototypeOf(fs).existsSync.call(fs, targetPath)
    })

  // 执行测试请求
  await request(app)
    .get('/your/target/controller/route')
    .expect(500)

  // 断言mock调用符合预期
  expect(existsSyncSpy).toHaveBeenCalledWith('/abs/path/to/your/email-template.html')
  // 单测结束Jest会自动还原原方法，也可以手动调用existsSyncSpy.mockRestore()即时还原
})

这种写法的核心优势：

• 无漏恢复风险，自动绑定测试用例的执行周期，不会跨用例污染
• 可通过mock实现做路径级精准匹配，其他模块、其他路径的fs.existsSync调用完全不受影响
• 适配同一个测试文件里同时测试多个路由、多个fs调用场景的需求

方案2：模块级定向mock（独立测试场景使用） #

如果你需要完全隔离目标控制器的fs依赖，不希望任何真实fs逻辑参与当前测试，可以用jest.mock的工厂函数做模块替换，配合Jest本身的测试沙箱隔离机制，从根源上避免跨测试文件的污染。
实际写法参考：

// 测试文件顶部声明，替换当前测试沙箱内的fs模块实现
jest.mock('fs', () => ({
  // 先加载fs的所有原生方法，避免缺失其他fs接口导致控制器报依赖错误
  ...jest.requireActual('fs'),
  // 单独重写existsSync的mock实现
  existsSync: jest.fn((targetPath) => {
    if (targetPath === '/abs/path/to/your/email-template.html') return false
    return true
  })
}))

it('模板不存在时返回500服务错误', async () => {
  // 当前测试沙箱内，所有导入fs的模块拿到的existsSync都是mock版本
  // 因为Jest默认每个测试文件运行在独立的模块沙箱中，这个mock不会影响其他测试文件的fs逻辑
  await request(app)
    .get('/your/target/controller/route')
    .expect(500)
})

注意：这个方案的mock生效范围是整个测试文件，适合给单个控制器写专属独立测试文件的场景；如果同个测试文件内还要测试其他依赖真实fs逻辑的路由，优先选择方案1。

手动替换写法的核心弊端 #

你当前用的const original = fs.existsSync; fs.existsSync = mockFn的写法，没有任何自动上下文管理机制：

• 一旦测试中途抛错、请求超时、supertest抛出异常，测试末尾的fs.existsSync = original恢复代码就不会执行，后续同文件内的所有测试用例都会用到被替换的mock方法
• 无差别替换时，所有路径的existsSync都会返回固定mock值，哪怕是其他模块判断配置文件、静态资源、目录存在性的正常逻辑，都会直接出错

内容的提问来源于stack exchange，提问作者Greg Wozniak