答案。

自动化测试分为单元（unit）、集成（integration）和端到端（end-to-end, E2E），以便在不同层次全面覆盖系统的验证。

问题历程: 这种分类源于需要同时测试应用程序的部分和整体。因此，测试层次如下：

• 具体功能（unit）
• 部件之间的交互（integration）
• 整个系统，从用户的角度看（E2E）

问题: 错误往往不仅出现在单个方法的逻辑中，还可能出现在组件之间的接合处，或在与外部服务“真实”启动整个系统时出现。如果把所有内容混在一起，很难快速定位错误或弄清楚它出现在哪里。

解决方案：

• 单元测试 检查孤立的代码，通常是在函数或简单类的级别。在高级情况下，使用模拟和桩。
• 集成测试 将多个组件（例如模块和数据库）连接在一起，以查看它们如何协同工作。
• 端到端测试（E2E）模拟用户场景——整个“从按钮到结果”的路径。

区分测试类型至关重要，以便：

1. 最小化维护成本（E2E 测试昂贵）
2. 保持快速的反馈（单元测试即时）
3. 减少误报的数量

关键特点：

• 正确分配测试有助于构建可靠的“金字塔”方法（测试金字塔）。
• 混合的测试风格会导致定位错误的问题。
• 清楚了解每层的目的可以实现最大的效率。

具有挑战性的问题。

可以把集成测试视为“更大的”单元测试吗？

不可以，集成测试测试多个组件的协同工作，而不仅仅是单个功能。同时，并不总能使用模拟——真实服务之间相互作用。

所有测试都应该是端到端（E2E）的吗？

不，这是昂贵和复杂的方法。E2E 仅在关键用户场景中需要，大多数逻辑由其他测试覆盖。

单元测试总是很快吗？

不总是。有时无法隔离代码，或者方法依赖于复杂的外部资源。在这种情况下，测试不再是单元测试。

常见错误和反模式

• 所有测试都进行端到端测试，反馈极其缓慢。
• 层次混淆：单元测试开始调用数据库或API，而E2E建立在模拟上。
• 只保留单元测试——组件间的关键错误无法捕捉。

生活中的例子

消极案例

在公司中，主要功能仅用E2E测试覆盖——每次修改都在夜间检查，测试不稳定，错误发现得很晚。

优点：

• 覆盖了真实的用户场景。

缺点：

• 缓慢的反馈。
• 处理故障原因费时。
• 许多误报。

积极案例

团队建立了测试金字塔：底层——单元测试，中层——集成测试，顶部——仅最重要的E2E。

优点：

• 快速了解代码哪里出故障。
• 测试维护更简单。

缺点：

• 在分层时需要良好的纪律。