3059行测试零模拟环境：开发者如何用Vitest搞定Cloudflare Workers验证

如何在不启动Cloudflare官方模拟环境的前提下，高效验证一个每天处理百万级流量的Worker？一位开发者的答案是：扔掉Miniflare，全程在Node下用Vitest加一个fetch存根，就完成了三千多行单元测试，还顺带揪出一个足以让广告计费体系静默崩盘的缓存缺陷。

这篇最初发布在Jo4博客上的实践复盘，提出了一个有些反直觉的结论：Cloudflare Workers本质上就是接收Request并返回Response的JavaScript函数，绝大部分业务逻辑根本不需要Workers运行时就能完成验证。作者在自己的Worker项目中累计添加了3059行测试代码，其中没有一行依赖Miniflare——那个被广泛推荐的Cloudflare Workers本地模拟环境。取而代之的，是Vitest的vi.stubGlobal('fetch', mockFetch)，一个简单的全局fetch替换。

具体来看这个Worker的入口结构。它不过是一个普通的对象方法导出：

export default {
async fetch(request, env, ctx) {
const url = new URL(request.url);
if (url.pathname.startsWith('/go/')) {
return proxyTrackingRequest(request, env);
}
if (url.pathname.startsWith('/blog/')) {
return proxyBlogRequest(request, env);
}
return proxyDefaultRequest(request, env);
}
};

输入是一个Web标准的Request对象，输出是一个Response对象。这意味着只要能在测试中构造Request、控制底层fetch的返回值，就能全面验证路由分发、缓存头设置、重定向处理等核心逻辑。Vitest的配置文件也没有任何特殊之处，仅仅是声明环境为node，并启用全局变量：

export default defineConfig({
test: {
environment: 'node',
globals: true,
},
});

没有专门的Workers环境配置，也没有Miniflare插件。测试套件在beforeEach钩子里创建mockFetch函数，再通过vi.stubGlobal('fetch', mockFetch)替换了Worker内部调用的全局fetch。这样一来，测试可以完全掌控后端API的返回状态、响应头以及状态码，不必真正发起任何网络请求。

作者特别强调了其中一个测试用例，因为它捕获了一个足以让广告计费系统失声的生产缺陷。这段测试的目标是验证追踪路由（/go/*）上不会出现任何缓存控制头：

it('does NOT set Cache-Control on tracking routes - clicks must not be cached', async () => {
mockFetch.mockResolvedValue(new Response('', {
status: 302,
headers: { 'Location': 'https://merchant.com/product' }
}));
const request = new Request('https://jo4.io/go/abc123');
const response = await worker.fetch(request, mockEnv, mockCtx);
expect(response.headers.get('Cache-Control')).toBeNull();
expect(response.headers.get('CDN-Cache-Control')).toBeNull();
});

表面上看这不过是一个寻常的缓存策略断言，但背后的业务逻辑却牵连着整个联盟营销的资金流。当用户点击推广链接进入 /go/abc123 时，Worker会生成独一无二的点击ID（jo4_cid），并向后端发送一次记录。假如Cloudflare在这个环节缓存了302重定向，后续所有对同一链接的访问都直接由边缘节点返回缓存的响应，请求根本不会再抵达源站。带来的后果非常直接：内容发布者看到的点击量停止增长，品牌方监测到的转化数归零，每一方都在为继续投放却收不到效果报告而付费。而这一切的根源，不过是某次部署中意外添加的一条Cache-Control响应头。

与之相对的是博客路由（/blog/*），它们会被主动施加上积极的缓存策略以加速访问；追踪路由则必须永远保持零缓存状态。这一个测试就同时验证了常规HTTP缓存头与Cloudflare专用CDN-Cache-Control头的缺失，确保Worker不会在生产环境中默默毁掉整个追踪链路。据作者描述，类似这样的边缘场景正是Miniflare这类模拟环境容易忽略的细节——当你的测试依赖完整的运行时环境去处理所有中间件和平台特性时，反而会把这类配置级的疏忽藏在大量无关响应的背后。

作者的实践观点很明确：将集成测试保留给部署后的线上验证，而在本地着力编写聚焦于路由决策、响应头控制、缓存指令的单元测试。用全局fetch存根替代真实Worker运行时的好处是测试执行极快，无需等待任何环境启动，也不会因为平台API的细微差异而引入假阳性。按照TL;DR的总结，这套方法更快、更简单，并且能抓到那些Miniflare无论如何都会漏掉的Bug。