Deno标准库中Mock测试工具与Expect断言库的兼容性问题解析

在Deno生态系统中进行单元测试时，开发者经常会遇到需要模拟(mock)函数调用的情况。Deno标准库提供了两套不同的测试工具：@std/testing/mock模块和@std/expect模块，但这两者之间存在一些兼容性问题需要开发者注意。

问题本质

核心问题在于@std/testing/mock模块中的stub函数创建的存根(stub)无法直接与@std/expect模块中的expect断言配合使用。当尝试使用expect(stub).toHaveBeenCalled()这样的断言时，会抛出"Received function must be a mock or spy function"错误。

这是因为两个模块采用了不同的实现机制：

• @std/testing/mock的stub函数主要关注替换原有函数实现
• @std/expect的断言系统需要函数具有特定的mock/spy标识

解决方案

目前有两种推荐的做法：

1. 统一使用@std/testing/mock模块 使用该模块提供的assertSpyCall等断言方法，保持测试代码的一致性。

2. 结合使用@std/expect的fn函数 可以通过fn创建mock函数，再将其作为stub的实现：

   const mockFetch = fn(() => Promise.resolve(...));
   const fetchStub = stub(globalThis, 'fetch', mockFetch);
   expect(mockFetch).toHaveBeenCalled();
   

技术背景

这种设计分离实际上反映了测试工具的不同设计理念：

• @std/testing/mock更偏向传统的存根和模拟方式
• @std/expect采用了类似Jest的mock/spy模式

对于TypeScript开发者来说，需要注意fn函数的类型限制，必要时需要进行类型断言。

最佳实践建议

1. 在新项目中，建议统一选择其中一种测试风格
2. 在已有项目中，保持现有测试风格的一致性
3. 对于复杂测试场景，可以考虑将两种方式结合使用，但要注意类型安全和可维护性

理解这些工具的设计差异和适用场景，可以帮助开发者更高效地编写Deno单元测试，避免常见的兼容性问题。