前段时间我写过一个测试，测试我在代码和第三方API之间编写的集成。测试确保集成正常运行并且我们恢复预期结果。
正式版本今天失败，因为测试在尝试连接第三方API时收到500错误。
测试这样的情况是否有意义？
答案 0 :(得分：11)
在我看来，如果第三方（db，webservice等）不可用，集成测试可能会失败。如果您不想测试集成本身，只想测试普通功能，您可以模拟API的结果并对其进行测试。在这种情况下，您的测试不再取决于第三方的可用性。
我通常根据具有“集成”等组属性的第三方可用性来标记单元测试，并将它们从连续集成过程中排除。相反，我让他们在夜间建造。集成测试通常在时间上很昂贵whole point of continuous integration is to provide rapid feedback。
答案 1 :(得分：4)
不，当第三方服务关闭时，您的测试套件失败没有帮助。但您确实希望完全测试与服务的集成。以下策略对我有用：
隔离模块中的第三方服务（假设一个类，但是你的语言模块化很好），除了封装服务的连接之外，尽可能少。在类上编写方法，以便可以区分服务错误的错误和错误的错误。例如，将服务关闭异常作为一个共同的超类。
编写服务类的单元测试，以便
如果发生服务中断错误，测试通过但记录错误。
如果发生任何其他错误，请照常失败。
编写这些测试，以便它们针对实时服务运行。应该有少量这些测试，因此它们不应该为测试套件运行时创建问题。
在所有其他测试中存储或模拟服务类，包括集成测试。 （通过“集成测试”，我在谈论测试自己代码的所有层的测试，而不是它们是否与第三方服务进行交互。）
当从集成测试中对服务类进行存根或模拟时，不要存根或模拟服务类的公共API，而是存根或模拟某些较低级别，也许是服务类或库的内部方法。您用来连接到服务。这可以防止在调用服务类时出现集成错误。在单元测试中，像任何类一样存根或模拟服务类的公共API。
正如Martin Buberl所建议的那样，对集成测试进行单独的测试运行可能会有所帮助，其中服务类没有被存根或模拟。说实话，这已经在我参与的多个项目中讨论过，但我认为它从未完成过。当第三方服务失败时，我们总是会从生产错误（通过监控或客户支持报告）中发现它，然后再从测试中发现它。