复杂前端系统的测试分层策略

复杂前端系统的测试不能只靠 E2E，也不能只靠单测。我的思路是先识别系统里哪些东西最稳定、哪些东西最容易变，再按风险分层验证。

第一层是纯逻辑单测。适合公式 AST、Schema 依赖图、缓存失效、权限判断、payload 校验、队列重试这些不依赖 DOM 的逻辑。它们出错影响面大，所以要用大量边界 case 固化行为。

第二层是组件和运行时测试。适合动态表单、插件渲染、Tiptap 原子节点、Trace 面板、动作模板渲染。重点不是测样式，而是测状态变化、生命周期、异常兜底和用户交互。

第三层是集成测试。适合 HATEOAS SDK 解析后端契约、埋点 SDK 代理 Fetch/XHR、多智能体平台从 Plan 到 Evidence 的流转。这里要验证多个模块组合以后，契约是否仍然一致。

第四层是场景回放和 E2E。适合弱网、页面卸载、长列表曝光、复杂拖拽、动态 Schema 编辑、AI Review Gate 等真实用户路径。E2E 数量不宜过多，但必须覆盖核心业务闭环。

第五层是上线后的观测验证。比如 SDK 自身错误率、埋点丢失率、Trace 中断率、插件加载失败率、动作模板缺失率。这类指标不是替代测试，而是补上测试环境覆盖不到的真实运行风险。

如果面试官问我怎么证明质量，我不会只说“写了很多测试”，而会说明每一层测试对应的风险是什么：单测防逻辑回归，组件测试防交互破坏，集成测试防契约漂移，E2E 防主路径断裂，线上观测防真实环境失明。