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-marketdsh-market 是 DeepSeek HarnessDSH内置的可视化插件市场负责插件的浏览、搜索与一键安装。它最核心也最容易出错的部分就是背后那条真实的 pnpm 安装链——从安装路由到包解析、校验、补丁层、热挂载任何一环出错都会让用户看到安装成功的假象。为了不让这类问题溜进生产项目用四层测试把整条链路包了起来。四层测试全景图一张表看懂分工整套体系沿用 deepseek-harness 的约定全部跑在 vitest 上Playwright 只作为库被测试代码调用从不是独立的 runner。官方说明见 TESTING.md。层测什么在哪命令CI1. 行为规格编排逻辑 可脚本化的 FakeDsh 模拟器覆盖全部 HTTP 路由tests/*.spec.tsnpm test每次 push2. 组件规格jsdom testing-library 直测真实 TSX 组件与本地化词典tests/client/*.client.spec.tsxnpm test每次 push3. Web e2e真实 dsh 组合启动 真实 Chromium 真实 pnpm 安装链tests/web/*.e2e.tsnpm run test:web独立任务4. 边界真实 pnpm 9/10/11/12 行为矩阵 打包/重启冒烟脚本tests/*.compat.spec.ts、scripts/*.mjsnpm run test:compat、npm run check独立任务单元 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_REQUIRED1把跳过变成硬失败。另外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逐项断言修复前后状态。文档里甚至保留了最近一次手工执行的时间和结果。值得抄进你项目的三条测试纪律 Red first先红后绿每个 bug 修复都带着能复现它的失败测试一起落地测试标题里的每个 issue 编号都是复现过、修好了。变异审计套件被专门做过定向变异测试——每个变异必须杀死至少一个用例每个用例都必须可被杀死不允许存在靠兜底路径就能过的断言。对推断保持怀疑市场的激活状态是推断就去找一个只可能是真的的地面真相夹具自证存活、重启后 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考