FEC 组件测试工作流

为什么组件测试容易退化成脆弱的快照

在前端开发中，随着业务逻辑的增加，组件测试很容易退化。开发者常常依赖 DOM 快照来断言组件渲染，或者 mock 了太多内部实现细节。这不仅让测试变得脆弱——只要重构内部结构就会导致大量无意义的失败，而且无法真正验证用户能感知到的行为。当组件处于 loading、empty 或 error 状态时，这些测试往往也无能为力，导致 UI 交互回归频发。我们需要一种更贴近代码和用户行为的测试方式，来验证纯逻辑、组件契约与轻量模块的协作。

如何构建高可维护性的组件测试

本技能提供了一套严谨的组件测试工作流，核心在于“按用户可感知行为测试”。

• 明确测试层级：首先区分单元测试、组件测试与轻量集成测试。纯函数、hooks 和状态逻辑走单元测试；组件的 props、emits 和回调走组件测试；涉及表单、API mock 与路由上下文的走轻量集成测试。
• 遵循 AAA 原则：每个测试必须清晰分段 Arrange（准备数据与渲染）、Act（执行用户动作）与 Assert（断言可见结果或公开契约）。
• 精准控制 mock 边界：mock 网络、时间和路由等外部依赖，但绝不 mock 被测组件的内部函数。mock 数据应表达真实业务场景，而不是随意的测试字符串。
• 覆盖关键状态：复杂组件必须覆盖默认渲染、用户交互、loading / empty / error 状态，以及适用的键盘焦点行为。

适用边界与避坑指南

这套工作流并非万能，它不能替代 E2E 测试。跨页面的真实浏览器流程仍需依赖 E2E workflow。此外，在编写测试时需要注意：

• 避免测试实现细节，如内部 state 名称或私有函数调用。
• 不要将 snapshot 作为交互组件的主要断言，它仅能辅助检查稳定的静态输出。
• 异步断言必须使用 findBy* 或 waitFor，严禁使用固定延迟。
• 回归测试必须先写能复现失败的最小测试，失败原因应指向用户行为或公开契约，而非测试环境问题。修复后必须保留该回归测试。