集成测试验证组件之间的通信路径和交互，以检测接口缺陷。
集成测试将模块收集在一起，并将它们作为一个子系统进行测试，以验证它们是否按照预期的方式进行协作，以实现更大的行为块。它们通过子系统执行通信路径，以检查每个模块对于如何与对等体交互的任何错误假设。
这与单元测试相反，在单元测试中，即使使用真正的合作者，其目标也是密切测试被测试单元的行为，而不是整个子系统。
虽然集成组件或模块的测试可以在任何粒度上编写，但在微服务体系结构中，它们通常用于验证集成代码层和它们所集成的外部组件之间的交互。
此类集成测试可用于测试的外部组件类型的例子包括其他微服务、数据存储和缓存。
与数据存储和外部组件的集成得益于集成测试的快速反馈
当编写与外部组件交互的模块的自动化测试时，目标是验证模块能够充分通信，而不是对外部组件进行验收测试。因此，这种类型的测试应该旨在覆盖通过集成模块的基本成功和错误路径。
网关集成测试允许任何协议级别的错误，如缺少HTTP头、错误的SSL处理或请求/响应体不匹配，都可以在尽可能精细的测试粒度中清除。
还应该测试任何特殊情况下的错误处理，以确保所使用的服务和协议客户机在异常情况下按预期响应。
有时很难触发外部组件的异常行为，如超时或响应缓慢。在这种情况下，使用外部组件的存根版本作为测试工具是有益的，它可以配置为以预定的方式失败。
在针对外部组件进行测试时，状态管理可能比较困难，因为测试将依赖于某些可用的数据。缓解这个问题的一种方法是商定一组固定的有代表性但无害的数据，保证在每个环境中都可用。
持久性集成测试保证代码假定的模式与数据存储中可用的模式相匹配。
在使用ORM的情况下，这些测试还提供了在工具中配置的任何映射都与返回的结果集兼容的信心。
现代orm在缓存和只在必要时刷新方面非常复杂。重要的是要构造测试，使事务在先决条件、操作和断言之间关闭，以确保数据进行完整的往返。
由于大多数数据存储都跨网络分区存在，因此它们也容易出现超时和网络故障。集成测试应该尝试验证集成模块是否能够妥善地处理这些失败。
这种风格的测试在重构或扩展集成模块中包含的逻辑时提供快速反馈。然而，它们也有不止一个失败的原因——如果集成模块中的逻辑退化，或者如果外部组件变得不可用或破坏了它的契约。
为了缓解这个问题，只需编写少量集成测试，以便在需要时提供快速反馈，并使用单元测试和契约测试提供额外的覆盖范围，以全面验证集成边界的每一侧。在CI构建管道中分离集成测试也是有意义的，这样外部中断就不会阻碍开发。
如果没有更粗粒度的微服务测试，我们就无法确信业务需求得到了满足
通过单元和集成测试，我们可以对组成微服务的各个模块中包含的逻辑的正确性有信心。
然而，如果没有更粗粒度的测试套件，我们就不能确保微服务作为一个整体一起工作以满足业务需求。
虽然这可以通过完全集成的端到端测试来实现，但通过测试与外部隔离的微服务，可以获得更准确的测试反馈和更小的测试运行时间
