在 Vue 应用中该进行单元测试的内容（以及不该触碰的部分）

Source: Dev.to

单元测试常常被当作项目清单上的一个勾选项。团队要么尝试把所有东西都测完，要么因为觉得测试慢、脆弱或难以维护而根本不写测试。
在 Vue 应用中，真正的挑战不是怎么写单元测试，而是到底哪些东西值得测试。

测试错误的内容会导致测试脆弱、频繁的重构痛苦以及一种虚假的自信感。测试正确的内容则会形成安全网，帮助重构、加快开发并提升长期可维护性。

在 Vue 应用中该单元测试什么

业务逻辑和纯函数

任何包含决策逻辑的代码都是单元测试的首选目标。

• 价格计算
• 验证规则
• 权限检查
• 数据转换
• 格式化逻辑

只要是有输入输出的纯函数，几乎都应该进行测试。

function calculateDiscount(price: number, isPremium: boolean) {
  return isPremium ? price * 0.8 : price
}

Composables

封装业务逻辑的 composable（而不仅仅是重新导出状态）是极佳的测试对象。

import { computed } from 'vue'

export function useUserAccess(user) {
  return computed(() => user.role === 'admin')
}

好的候选包括数据获取 composable、状态机、功能标志逻辑以及复杂的响应式流。

Store

Store 往往承载业务规则，应该测试：

• 修改状态的 actions
• 带有逻辑的 getters
• 错误处理路径
• 副作用的编排

通常不需要测试简单的状态赋值或仅返回值的 trivial getter。

测试行为，而非实现细节

关注可观察的结果，例如：

• 错误状态
• 空数据
• 无效输入
• 边界条件

这些场景在生产环境中往往会悄然失效，且没有测试时最难排查。

不该单元测试的内容

Vue 内部实现和框架行为

以下内容不必测试：

• v‑if 是否工作
• v‑model 是否正确更新
• 响应式是否更新 DOM
• 生命周期钩子是否被调用

Vue 已经保证了这些行为，测试它们只会增加噪音而没有价值。

避免过于具体的 UI 断言

不要断言：

• 精确的 HTML 结构
• 除非影响逻辑的 CSS 类
• 像素级的渲染

这类测试脆弱且在无害的重构时会失效。如果需要视觉准确性，可考虑视觉测试、适度的快照测试或端到端测试。

没有业务逻辑的组件

如果一个组件：

• 仅把 props 传递给子组件
• 没有分支行为
• 没有内部逻辑

……通常不需要单元测试。集成测试或 E2E 测试能够更有效地覆盖这些情况。

避免耦合内部实现

不要依赖：

• 内部变量名
• 特定的响应式结构
• 内部的 ref 或 watcher

好的测试应验证可观察的行为，而不是实现方式。

均衡的 Vue 测试策略

• 单元测试 保护业务逻辑和边缘情况。
• 集成测试 验证组件之间的协作。
• 端到端测试 保障用户流程。

为每个测试自问：

1. 如果行为出错，这个测试会失败吗？
2. 这个测试能在重构后仍然通过吗？
3. 这个测试是提升信心，还是仅仅在提升覆盖率？

高价值测试 关注点明确、稳定且有意图。
低价值测试 脆弱、冗余且依赖框架实现。

目标不是追求最高覆盖率，而是让每个编写的测试都能提供最大的信心。

在 Vue 中进行单元测试并不是要把所有东西都测，而是要测对东西。精挑细选的测试能够带来信心和速度。请有意识地编写测试——你的未来的自己会感谢你的。

祝编码愉快！ 🖥️