构建工具本身的测试往往比业务代码更隐蔽，Webpack 5的配置一旦出错，通常到生产环境才暴露问题。例如publicPath配置错误会导致所有异步chunk加载失败，代码分割规则写错可能让首包体积翻倍，持久化缓存配置不当则可能让增量构建完全失效。因此，Testing测试策略不能只盯着业务模块的单元测试，还需要把webpack配置、构建产物以及运行时加载行为纳入验证体系，形成一套面向构建链路的测试方案。

一、把Webpack配置当作被测对象

Webpack 5的配置文件本质上是运行在Node环境下的JavaScript代码，这意味着它同样具备可测试性。很多人修改完optimization.splitChunks或者cache字段后直接执行构建，等到产物体积异常才发现配置写错。更好的做法是为关键配置项编写断言，例如检查mode是否处于生产环境、output.publicPath是否以斜杠结尾、cache.type是否设置为filesystem。这些断言可以放在独立的Node脚本里，借助webpack自身的Node API读取配置对象。

例如下面这段脚本会在不触发完整构建的情况下读取并校验配置，提前拦截低级错误：

const config = require('./webpack.config.js');
function assertConfig(cfg) {
  if (!cfg.mode || cfg.mode !== 'production') {
    throw new Error('生产构建必须设置 mode 为 production');
  }
  if (!cfg.output || !cfg.output.publicPath) {
    throw new Error('output.publicPath 未配置，异步chunk将无法正确加载');
  }
  if (!cfg.cache || cfg.cache.type !== 'filesystem') {
    throw new Error('生产缓存建议使用 filesystem 类型');
  }
}
assertConfig(config);
console.log('webpack配置基础校验通过');

除了静态校验，还可以通过webpack的schema校验器检查配置是否为官方认可的格式。webpack 5内置了配置项的类型检查和默认值合并逻辑，直接调用validateSchema可以暴露拼写错误、字段名大小写错误等问题。这一步骤虽然轻量，但能显著降低配置漂移带来的构建失败概率。

二、构建产物与运行时加载验证

配置正确不代表产物可用，还需要验证webpack输出的文件是否符合预期。最常见的做法是在构建完成后用Node脚本扫描dist目录，检查入口文件、异步chunk、source map等资源是否生成，并且文件名是否与output.filename规则一致。对于启用了contenthash的场景，文件名中应该包含对应的哈希片段，这可以通过正则表达式来断言。

下面这段代码展示了如何检查构建产物中是否包含具备contenthash的入口文件和独立的异步chunk：

const fs = require('fs');
const path = require('path');
const distDir = path.resolve(__dirname, 'dist');
const files = fs.readdirSync(distDir);
const mainFile = files.find(file => /^main\.[a-f0-9]{8}\.js$/.test(file));
if (!mainFile) {
  throw new Error('入口文件缺少 contenthash 或命名不符合预期');
}
const asyncChunk = files.find(file => /^src_[a-zA-Z0-9]+\.[a-f0-9]{8}\.js$/.test(file));
if (!asyncChunk) {
  throw new Error('异步chunk未生成，请检查代码分割配置');
}
console.log('产物文件基础校验通过');

运行时的验证比静态检查更接近真实用户场景。webpack 5的模块系统在浏览器中执行时，会依赖runtime代码来加载chunk和联邦模块。可以使用Playwright或Puppeteer启动无头浏览器，加载打包后的HTML页面，通过window暴露的全局变量或者页面DOM来判断业务模块是否正确执行。如果项目使用了publicPath为CDN地址，还可以在测试中模拟网络请求失败，验证错误处理逻辑和重试机制。

三、模块联邦与缓存专项测试

模块联邦是Webpack 5引入的重点特性，它允许不同构建之间共享模块。但在测试策略中，模块联邦很容易被忽略，因为它的行为涉及远程入口加载、共享依赖版本协商以及边界情况的降级处理。测试时需要单独启动一个remote应用或者使用静态的remoteEntry.js文件，然后在host侧加载远程模块并调用其导出的函数。如果远程模块加载失败，需要确保host端能够捕获错误并给出友好的降级提示。

以下是一个简化版的Playwright测试脚本，用来验证remote模块是否能够被正确消费：

const { test, expect } = require('@playwright/test');
test('远程模块应能正常加载并执行', async ({ page }) => {
  await page.goto('http://localhost:3000/host.html');
  const result = await page.evaluate(async () => {
    const remoteModule = await window.loadRemote('app_remote', './Button');
    return remoteModule.default().textContent;
  });
  expect(result).toContain('远程按钮');
});

持久化缓存是另一个需要专项测试的重点。webpack 5的filesystem缓存可以在二次构建时跳过模块转换和依赖解析，大幅缩短构建时间。但缓存失效的条件比较复杂，例如配置文件变化、node_modules版本更新、webpack自身版本升级等都会触发缓存重建。测试中可以记录首次构建耗时和缓存文件生成情况，修改一个无关源文件后再次构建，断言耗时显著下降；再修改cache.buildDependencies中声明的配置文件，断言缓存目录发生变更并重新构建。

四、自动化与回归测试的落地

将上述验证步骤整合到持续集成流水线中，才能让测试策略真正生效。建议把测试分成两个阶段：构建前阶段运行配置校验和schema校验，构建后阶段运行产物检查和运行时验证。对于体积敏感的团队，还可以在CI中加入构建产物体积快照对比，当入口文件或异步chunk体积超出设定阈值时直接阻断合并。

测试用例的维护同样需要遵循软件工程原则。避免为每一个细小的配置项都写断言，而是关注影响用户体验的核心行为，例如首屏加载资源数量、缓存命中率、异步chunk的加载失败率等。当webpack配置发生变更时，先更新测试预期，再修改实现，这样可以把配置演进的过程纳入可追踪、可回滚的版本管理体系中。

最后需要留意的是，测试策略本身也会引入复杂度。不要为了让覆盖率达标而增加大量脆弱的浏览器端测试，优先保证构建产物在目标浏览器中的基本可运行性，再逐步补充模块联邦、缓存等专项测试。合理的测试分层能让Webpack 5的新特性在可控风险下得到应用。