集成测试应该包含多少内容？在哪里测试副作用？

Posted 2023-02-23

【中文标题】集成测试应该包含多少内容？在哪里测试副作用？

【英文标题】：How much should an integration test contain? Where are side effects tested?

【发布时间】：2014-05-12 22:11:52

【问题描述】：

假设我有一个功能要求，当用户成功注册付费帐户时，会发生几件事：

用户帐户已创建 用户的信用卡被扣费，产生新的交易记录 收据通过电子邮件发送给用户

我见过的大多数 rspec 集成或黄瓜测试都非常专注于屏幕上显示的内容，例如expect(page).to have_text(X) 或 Then I should see X

集成测试应该涵盖多少？

集成测试是否应该检查...

已创建客户记录？ 事务已创建？ 交易金额是否正确？ 收据电子邮件已发送？

为什么或为什么不？如果没有，应该在哪里/如何测试这些类型的副作用？

【参考方案1】：

如果您在外部进行开发，您的大部分集成测试将是验收测试。这些是关于用户所看到的，因此他们从外部与系统交互。他们不查看数据库或以其他方式进入幕后。他们不需要：如果有理由将某些内容保存在数据库中，如果它出现在屏幕上，我们就会知道它是否有效。他们确实需要测试是否已发送电子邮件或是否在第三方信用卡处理系统中创建了一个帐户，因为这些是用户看到的一部分。

在您实施了所有验收测试后，您可能会将系统视为一名工程师，并决定系统中的类如何与其他类或与外部系统交互的某些方面没有经过充分测试。首先，确定这些是否告诉您真正应该在验收测试中出现的需求（通常是这种情况），如果是，请改进验收测试。

您可能仍然觉得需要编写更多不是验收测试的集成测试，它们可能需要直接查看数据库或其他内容。根据我的经验，这些是少数。

也就是说，有时验收测试在场景中间停止并仅测试副作用是有实际意义的，因为另一个验收测试已经描述了场景的其余部分。 （例如，可能有 18 种不同的方法可以在您的应用程序中创建帐户。也许它们都会在中期场景中导致数据库中的相同帐户。）同样，您可能想要伪造一些数据库状态并在中期开始- 避免重复的场景；通常通过用户登录来执行此操作。

在您的应用程序实现所有验收测试并具有良好的集成覆盖率后，使用单元测试测试细节，这会测试副作用。但是，如果您的验收/集成测试已经充分测试了一段给定的代码，那么它就不需要单元测试，而且它的副作用可能永远不会被直接测试——这很好。

【讨论】：

感谢您的详尽回答。要测试副作用，您会建议导航到用户可见的位置并验证它的存在吗？例如在注册时处理付款后，导航到付款历史记录页面并查找付款？当它是一个外部服务时，你如何处理它——比如我在 Twitter 上发帖；我的验收测试如何验证推文确实已发布？其效果对生产中的用户来说是“可见的”，但我的测试实际上不会发布到 twitter - 它会被模拟出来。

对于应用程序内部的副作用，正如您所说。外部服务更难，技术也多种多样。举几个例子：Rails 有一个邮件测试模式，它不发送邮件，但让您检查邮件是否已发送。我使用的最新信用卡处理系统有一个可以运行集成测试的测试服务器。对于 Twitter 之类的东西，您可以在真实服务上使用测试帐户。有时没有好的方法可以做到这一点，即使在集成测试中也必须进行存根或模拟。