安息吧，集成测试
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...
