Viv*_*ath 11 testing continuous-integration integration-testing automated-tests regression-testing
我前段时间编写了一个测试,用于测试我在代码和第三方API之间编写的集成.测试确保集成正常工作,并确保我们得到预期的结果.
正式版本今天失败,因为测试在尝试连接到第三方API时收到500错误.
测试这样的情况是否有意义？
Mar*_*erl 11
在我看来,如果第三方(db,webservice等)不可用,集成测试可以失败.如果您不想测试集成本身,只想测试普通功能,您可以模拟API的结果并对其进行测试.在那种情况下,您的测试不再依赖于第三方可用性.
我通常根据具有"集成"等组属性的第三方可用性来标记单元测试,并将它们从连续集成过程中排除.相反,我让他们在夜间建造.集成测试通常在时间上是昂贵的,并且持续集成的整个点是提供快速反馈.
不，当第三方服务关闭时，测试套件失败对您没有帮助。但是您确实希望完全测试您与服务的集成。以下策略对我很有效：
将第三方服务隔离在一个模块中（假设是一个类，但是你的语言模块化很好），除了封装到服务的连接之外，它尽可能少地做。在类上编写方法，以便可以区分服务的错误和您的错误的错误。例如，为服务中断异常提供一个通用超类。
编写服务类的单元测试，以便
如果发生服务关闭错误，测试通过但记录错误。
如果发生任何其他错误，请照常失败。
编写这些测试，以便它们针对实时服务运行。这些测试的数量应该很少，因此它们不应为测试套件运行时带来问题。
从所有其他测试（包括集成测试）中存根或模拟服务类。（这里的“集成测试”是指测试您自己代码的所有层的测试，而不是它们是否与第三方服务交互。）
当在集成测试中存根或模拟服务类时，不要存根或模拟服务类的公共 API，而是存根或模拟一些较低级别，可能是服务类的内部方法或您使用的库连接到服务。这可以防止在调用服务类时出现集成错误。在单元测试中，像任何类一样存根或模拟服务类的公共 API。
正如 Martin Buberl 所建议的那样，在服务类未被存根或模拟的情况下，单独运行集成测试可能会有所帮助。老实说，这是我参与的多个项目中讨论过的事情，但我认为从未做过。当第三方服务失败时，我们总是先从生产错误（由监控或客户支持报告）中发现它，然后再从测试中发现它。