TL;DR
绝大部分集成测试都可以被“实现合理”的端到端验收测试所代替。集成测试这个概念应该从测试金字塔中去掉。
引子
最近看到好几篇文章提到集成测试（以下简称 IT）在开发中的作用，常说单元测试（以下简称 UT）和验收测试（以下简称 AT）不够用，所以应该上集成测试，等等。这与我最近这一年多的开发经历非常不一致，我不写 IT，只写 AT 和 UT（我是 XP 和 GOOS 的铁粉）。在 TDD 讨论群里，就集成测试和相关话题也和很多朋友聊了不少，感觉是时候写篇文章了。
到底什么是集成测试？
首先让我们看看到底什么是集成测试。其实这个问题很难回答，我从来没见一个合理和明确的定义。鉴于此，这里就用我自己的定义了。简单来说，集成测试就是一种自动化测试，目的是用来“集成”我们的代码，以确保几个代码模块放在一起是可以工作的。
上图是一个简单的网页表单+数据库的应用架构示意图，以 Java / Spring 框架来实现。那么，IT 可能覆盖的代码用虚线椭圆框表示，而 AT 会覆盖所有的代码，UT 则只针对某一个类或者模块。由图可见，集成测试由于缺乏共识，不同团队的实践也不一样，比如有些会把数据库包含在内，另一些则只是包含框架，Controller 和 Domain Object。另一种情况是，团队并不明确区分 UT 和 IT，而是用“Mini Integration Test” 来代替两者。这种情况与单元测试有关，本文就不讨论了。
什么是验收测试以及“端到端”？
验收测试的定义很明确，不论是 XP 中还是实例化需求中，都会把 AT 当做一个有业务价值的场景来看。而且 AT 可以把这样的场景“运行”起来，以此来验证业务价值没有被破坏。根据定义，通常实现 AT 的时候是“端到端”的。以我之前的经验，要把 AT 做好，关键是要理解“端到端”应该从团队视角出发，而不是用户视角出发。
如上图，用户在 App 上注册这个功能如果从用户视角来看，那么端到端就是从注册开始，直到他收到欢迎邮件为止。但如果从团队视角来看，端到端则变成从注册开始到 Api 后端服务将发送欢迎邮件的请求发送给 CRM 系统为止。如果是用户视角的 AT，最终的验证点是用户是否收到邮件（技术上是可行的），而团队视角的 AT，则只要验证是否正确发送请求就可以了。当然现实往往是残酷的，不少公司 App 和 Api 就是分为两个团队开发，那么 App 团队的 AT 就是到发送请求给 Api 为止，Api 团队的 AT 则是从接收到 Api 请求开始。
我的建议是以团队视角实现 AT，在测试中对所有外部依赖进行隔离（如 CRM 系统，就可以用 mock server 来验证请求并给出假的响应数据 ）。实话说，绝大部分应用都有不可控的外部依赖（可能来自组织内部或外部），以用户视角来实现 AT 在实际工作中将变得不切实际，难以落地。
集成测试和验收测试的特点比较
有了定义之后，就可以比较一下 IT 和 AT 了，请看下表：
| 集成测试 | 验收测试 | |
| 目的 | 集成代码并确保代码放在一起是可以工作的 | 代表有业务价值的场景并确保其不被破坏 |
| 实现复杂度 | IT 通常需要启动框架或容器，涉及数据库或 Api 调用时，要进行必要的数据控制和 Mock 后端服务的 IT 不会打开 App 或者浏览器这样的 GUI。而前端代码的 IT 则不会启动所需的服务 |
AT 需要启动整个被测系统，对所有涉及的数据和 Api 进行控制 AT 会打开 App 或者浏览器来进行测试，测试运行会“途径” 代码中的每一层 |
| 运行时间 | IT 运行的时间介于 UT 和 AT之间，一个 IT 大概是几百毫秒到一两秒 | AT 运行的时间比 IT 长，一个 AT 大概是几秒到几十秒。 如果 IT 和 AT 都做同样的数据控制并 Mock 外部依赖，那么两者的时间差主要是启动 App 或者浏览器所需要的时间 |
| 运行环境的复杂度 | IT 的运行环境通常是模拟环境，可能不用启动整个被测系统。比如，基于 Spring 框架的 IT 就可以利用 SpringJUnitRunner 来实现 | AT 的运行环境是和开发环境一致的，仅仅是环境配置不同（比如测试数据库的链接） |
| 定位问题的难度 | 如果 IT 失败，定位问题其实并不容易，因为涉及代码也不少 | 如果 AT 失败，定位问题更难，因为涉及了整个系统 |
为什么说应该用验收测试来代替集成测试？
基于上面的比较，来看看为什么验收测试可以代替集成测试吧：
- 目的：IT 的目的是集成代码，代表业务场景的 AT 一样可以集成代码，而且集成的代码更加完整并有业务上的意义。这回合，AT 完胜 IT。
- 实现复杂度：在 IT 出现的年代，端到端测试框架和服务Mock技术尚不成熟，实现 IT 的复杂度的确比 AT 要低不少。然而，现在这些框架和工具都已经很成熟了，如 cucumber ruby 的生态圈（包括 cucumber/capybara/selenium/appium/mock-server/factory-bot/activerecord 等等），AT 的实现复杂度已经大大下降了。这回合，AT 胜在生态圈已经追平甚至超过 IT 了。
- 运行时间：这恐怕是 IT 的拥护者们最有信心的一点了，IT 就是比 AT 快，还快不少呢。的确，即使以目前的技术，AT 的运行时间依然是 IT 的10 倍左右。不过，我想说这个关注点错了。道理很简单，在提交代码之前，绝大部分提交都不需要运行所有的 AT，只要运行代码修改相关的那些就可以。而这些 AT 的数量不多，加在一起就是一两分钟到几分钟的时间，也不需要像单元测试那样频繁的运行。AT 的全集则可以在 Jenkins 这样的 CI 服务里面定期运行。因此，这回合 AT 至少可以和 IT 打个平手。
- 运行环境的复杂度：这一点其实和“实现复杂度”类似。由于开发机（如 MacBook Pro）的性能提升和虚拟机容器技术的发展，使得开发机上已经可以安装几乎所有生产环境所需的服务了。AT 运行环境搭建的复杂度大大下降，加上基本是一次性工作（也能自动化），AT 同样胜在日益强大的生态圈。
- 定位问题的难度：实话说，这一点 IT 和 AT 是打平的，因为都不胜任。单元测试才是定位问题（准确的说是预防问题）的生力军，IT 和 AT 只能靠边站。
之前不少文章认为写和维护 AT 的成本比 IT 要高，我对此说法并不认可。在我看来写 AT 的成本由于测试框架和工具的发展已经变得很低了，至少可以和 IT 打个平手。而维护 AT 的成本则更是和测试代码本身的设计和重构有关，和自动化测试的类型无关。即使是 IT 和 UT，只写不重构，依然会得到难以维护的测试代码。因此，经过一些辅导和实践，写和维护 AT 的成本不会高于 IT 很多，是完全可以接受的。
对于新开发的系统，我建议尽量以 AT 和 UT 先行的方式来开发，因为只有让 AT 写在代码之前，才能更早的发现一些系统级依赖并隔离掉。对于遗留代码系统，我会尽早建立 AT 防护网（其实并没想的那么难），同时对要修改的代码进行最小范围隔离并加 UT 。
什么样的集成测试是有意义的？
集成测试依然有适合的场景，比如：
- 有时团队的外部依赖（如之前那个 CRM 系统）很不稳定，要么接口频繁修改，要么测试环境天天出状况。为了应对这种情况，团队可以考虑对外部依赖编写一些 IT，用来监控（Liu Zheng Ju）和及时沟通（Che Pi）。
- 如果多个团队共同开发一个系统（如之前的 App+Api 团队和 CRM 团队），那最好还是写有一套从用户视角出发的 AT。当然，这些 AT 实现和运行环境的复杂度较团队视角 AT 更高，运行时间更长，而且谁来写会是一个需要沟通（Si Bi）的事情。
结束语
本文并不是说现在很多团队写的 IT 都是错误或者无用的，无论哪种自动化测试，都是回归测试的生力军。而且只要团队愿意，在现有 IT 技术栈的基础上引入一些新的测试框架和工具并非难事，完全可以在未来逐步实践 AT，让自动化测试更好的关注在业务场景上。
最后，非常感谢 TDD 讨论群里面诸多小伙伴的无私反馈和讨论，没有这些反馈和讨论是不会有这篇文章的。由于参与讨论的人很多，这里就不一一列举名字了。
R.I.P Integration Test; Long Live Acceptance Test and Unit Test.