DeepSeek Harness 源码解析 · 第 42 讲
DeepSeek Harness 源码-测试架构与快照测试 第 42 讲：三模式快照系统、DOM 序列化器、test-invariants 全局屏障 💡 本讲一句话 dsh 不靠 mock 求确定性，而是把"真实 API 交互录一次、之后永远回放"做成三模式快照系统（replay/record/refresh）；DOM 快照用自定义序列化器归一化 CSS-module 类名和 SVG 指纹，让样式改动不再搅动 .snap；test-invariants.ts 则 monkey-patch cordis 的 plugin() 给所有测试根装上 invariant 屏障——确定性、零配额、不 mock。 一、三模式快照系统：replay / record / refresh package.json （L36-L47）把测试拆成一组语义明确的脚本，核心是 DSH_SNAPSHOT 环境变量驱动的三模式： 📄 package.json（L34-L47，节选） "test": "vitest run", // 默认全量单测（无快照） "test:snapshot": "vitest run --config vitest.snapshot.config.ts", // 快照回放：零 API、零配额，CI 默认跑这个 "test:snapshot:record": "DSH_SNAPSHOT=record vitest run --config vitest.snapshot.config.ts --update", // 录制模式：调真实 API，更新 fixture + golden（唯一花钱的模式） "test:snapshot:refresh": "DSH_SNAPSHOT=refresh vitest run --config vitest.snapshot.config.ts", // 刷新模式：回放已提交脚本，只回写当前期望输出（不花配额） "test:e2e": "vitest run --config vitest.e2e.config.ts", // E2E：真实子进程路径 "test:web:perf": "npm run build && npm run test:web:perf:built", // 性能回放：先构建再跑（DSH_SNAPSHOT=replay） "check:all": "tsx scripts/run-gates.ts check-all", // 门禁聚合入口 为什么这样设计： 三模式把"花钱的录制"和"免费的回放"彻底分开——CI 永远跑 replay（零配额、确定性），只有开发者本地显式 record 才消耗真实 API。refresh 是中间态：模型响应从已录 fixture 回放（不花钱），但把"当前代码组装出的请求/输出"回写成新 golden——用于"行为变了、要更新期望"的场景，而不是"重新调一次 API"。 二、vitest.snapshot.config.ts：模式决定并发 vitest.snapshot.config.ts （68 行）把模式语义直接编码进并发策略——这是"确定性优先于速度"的又一例： 📄 vitest.snapshot.config.ts（L6-L37） const DEFAULT_SNAPSHOT_MAX_CONCURRENCY = 5 // 默认并发上限：5（受 CPU 核数约束，见 L21） function positiveIntFromEnv(name: string, fallback: number): number { // 环境变量解析器：非法值直接抛错 const raw = process.env[name] // 读原始字符串（可能未设置/空串） if (raw === undefined || raw === '') return fallback // 未设置 → 用默认值（不猜、不静默） const value = Number(raw) // 转数字 if (!Number.isInteger(value) || value < 1) { // 非正整数 → fail loud throw new Error(`${name}…