绝大部分集成测试都可以被“实现合理”的端到端验收测试所代替。集成测试这个概念应该从测试金字塔中去掉。
引子
最近看到好几篇文章提到集成测试（以下简称 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.
