dsh-market 测试体系拆解：四层测试如何守护真实 pnpm 安装链

dsh-market 测试体系拆解：四层测试如何守护真实 pnpm 安装链

【免费下载链接】dsh-marketThe plugin market inside DeepSeek Harness — browse, search, one-click install · DSH 可视化插件市场项目地址: https://gitcode.com/gh_mirrors/ds/dsh-market

dsh-market 是 DeepSeek Harness（DSH）内置的可视化插件市场，负责插件的浏览、搜索与一键安装。它最核心也最容易出错的部分，就是背后那条真实的 pnpm 安装链——从安装路由到包解析、校验、补丁层、热挂载，任何一环出错都会让用户看到"安装成功"的假象。为了不让这类问题溜进生产，项目用四层测试把整条链路包了起来。

四层测试全景图：一张表看懂分工

整套体系沿用 deepseek-harness 的约定：全部跑在 vitest 上，Playwright 只作为库被测试代码调用，从不是独立的 runner。官方说明见 TESTING.md。

单元 lane 的配置在 vitest.config.ts 中刻意排除了 compat 用例，保证日常npm test快速、无网络、不碰真实 pnpm。

为什么第 3 层必须跑"真实机器"？

这是整个体系里最反直觉、也最重要的一层。

第 1 层虽然也驱动安装链，但驱动的是仓库里手写的FakeDsh模拟器。它只能证明"代码符合我们对 pnpm 和 cordis 的理解"——而历史上真正发货的安装 bug（#103、#122、#135、#147）全是我们的理解错了，所以再多第 1 层用例也堵不住这个洞。只有真实机器能堵。

于是 tests/web/install.e2e.ts 让真实的 pnpm、真实的 loader、真实的补丁层跑完整条链：

• 本地 npm registry 喂包：夹具插件由 tests/web/registry.ts 在 localhost 上以真实 packument + tarball 形式提供。市场、pnpm、cordis 走的都是普通代码路径，什么都不需要发布，也完全不碰外网。
• 夹具"自证活着"：每个夹具在apply()内部注册自己的存活标记（见 fixture-a/cordis.patch.yml）。只有 cordis 真的解析了包、加载了模块、执行了它，标记才会出现。市场的activation[name].state只是一个推断，测试拿它和这个"地面真相"对账，而不是直接信任它。
• 场景来自真实事故：拒绝 loader 条目重复（#122）、禁用插件不误伤邻居（#147）、重启后状态要和市场说法一致（#156）、用户中途离开页面卸载也要干净（#163）……测试标题里的每个 issue 编号，都是一次"先复现、再修复"的事故。

e2e 脚手架：可跳过，但不许"假绿"

启动真实 dsh 组合的脚手架是 tests/web/scaffold.ts，它把打包后的市场装进一次性DSH_HOME并交给测试一个基地址。这里藏着一个很精巧的防线设计：

• 开发者机器上没有 dsh CLI 时，e2e自动跳过——跳过是对的。
• 但 CI 自己会安装 CLI，如果安装步骤坏了而 e2e 静默跳过，CI 就会报出一个"什么都没断言的绿"。所以 CI 设置DSHM_E2E_REQUIRED=1，把跳过变成硬失败。

另外，tests/web/market.e2e.ts 用真实 Chromium 走完整的 UI 旅程，并挂了一个控制台"绊线"——页面一出现任何 console 错误，整个测试直接失败。

第 4 层：用真实 pnpm 钉死失败签名

tests/pnpm-behavior.compat.spec.ts 在一次性 profile 夹具里跑真实的 pnpm 9/10/11/12，把 #20/#21/#22 背后的失败签名逐一钉住。例如 pnpm 9 在 workspace 根目录不带-w会报ERR_PNPM_ADDING_TO_ROOT，而所有 pnpm 大版本在非 workspace 里带-w都是硬错误——所以-w的注入必须依赖 profile 的真实形态，而不是拍脑袋。

对应的分类决策逻辑在 tests/pnpm-compat.spec.ts 中单测覆盖：hoist 模式差异、幽灵依赖 404（#65）、补丁打不上（#222）、Windows 文件锁（#389）……每种 pnpm 报错都会被翻译成用户能看懂、知道下一步做什么的提示。

配套约定很直白：Fake pnpm 从不发明行为——模拟器里的每个行为，都是先被这条真实 pnpm lane 钉过签名的。

一条所有自动化都覆盖不到的手动检查

所有自动化 lane 里 pnpm 都是现成的，唯独provisionPnpm（界面上"缺少一个小组件"横幅 + 一键修复）只能对着 mock 测。而它恰是用户报告密集区（#105、#108、#132）。

自动化它意味着每次运行前在 runner 上装 pnpm、之后再删掉——脆弱到会经常因自身原因失败。所以 TESTING.md 把它诚实地记为一条刻意的手动检查：在 pnpm 可达时构建 profile → 把 pnpm 二进制挪走（仅从 PATH 删掉不够，因为spawnEnv会刻意补回常见 bin 目录）→ 把npm_config_prefix指到一次性目录 → 启动 dsh，确认pnpm: false，再 POST/dsh-market/setup-pnpm，逐项断言修复前后状态。文档里甚至保留了最近一次手工执行的时间和结果。

值得抄进你项目的三条测试纪律 📌

1. Red first（先红后绿）：每个 bug 修复都带着能复现它的失败测试一起落地；测试标题里的每个 issue 编号都是"复现过、修好了"。
2. 变异审计：套件被专门做过定向变异测试——每个变异必须杀死至少一个用例，每个用例都必须可被杀死；不允许存在"靠兜底路径就能过"的断言。
3. 对推断保持怀疑：市场的激活状态是推断，就去找一个"只可能是真的"的地面真相（夹具自证存活、重启后 profile 能不能起来）来对账。

四层各司其职：第 1、2 层管快速迭代与界面，第 3 层用真实机器守住安装链，第 4 层用真实 pnpm 版本矩阵钉住边界行为。这正是"一键安装"四个字背后真正的成本——不是写得快，而是验证得真。

【免费下载链接】dsh-marketThe plugin market inside DeepSeek Harness — browse, search, one-click install · DSH 可视化插件市场项目地址: https://gitcode.com/gh_mirrors/ds/dsh-market