如何测试与第三方API的连接是否适合持续集成？

在我看来，如果第三方（db，webservice等）不可用，集成测试可以失败。如果您不想测试集成本身，只想测试普通功能，您可以模拟API的结果并对其进行测试。在那种情况下，您的测试不再依赖于第三方可用性。 我通常根据具有“集成”等组属性的第三方可用性来标记单元测试，并将它们从连续集成过程中排除。相反，我让他们在夜间建造。集成测试通常在时间上是昂贵的，并且持续集成的整个点是提供快速反馈。     

不，当第三方服务关闭时，您的测试套件失败是没有用的。但您确实希望完全测试与服务的集成。以下策略对我有用： 隔离模块中的第三方服务（假设一个类，但是你的语言模块化很好），除了封装与服务的连接之外，尽可能少。在类上编写方法，以便可以区分服务错误的错误和错误的错误。例如，为服务关闭异常提供一个共同的超类。 编写服务类的单元测试 如果发生服务中断错误，测试通过但记录错误。 如果发生任何其他错误，则照常失败。 编写这些测试，以便它们针对实时服务运行。应该有少量这些测试，因此它们不应该为测试套件运行时创建问题。 在所有其他测试中存储或模拟服务类，包括集成测试。 （通过“集成测试”，我在谈论测试自己代码的所有层的测试，而不是它们是否与第三方服务进行交互。） 在集成测试中存根或模拟服务类时，不要存根或模拟服务类的公共API，而是存根或模拟某些较低级别，可能是服务类的内部方法或您用于的库连接到服务。这可以防止在调用服务类时出现集成错误。在单元测试中，像任何类一样存根或模拟服务类的公共API。 正如Martin Buberl所建议的那样，对集成测试进行单独的测试运行可能会有所帮助，其中服务类不会被存根或模拟。说实话，这已经在我参与的多个项目中讨论过，但我认为它从未完成过。当第三方服务失败时，我们总是会从生产错误（通过监控或客户支持报告）中发现它，然后再从测试中发现它。