假设我有一个功能要求，当用户成功注册付费帐户时，会发生几件事：
我见过的大多数 rspec 集成或黄瓜测试都非常专注于屏幕上显示的内容，例如expect(page).to have_text(X) 或 Then I should see X
集成测试应该涵盖多少？
集成测试是否应该检查...
为什么或为什么不？如果没有，应该在哪里/如何测试这些类型的副作用？
【问题讨论】：
标签： ruby-on-rails rspec cucumber integration-testing acceptance-testing
如果您在外部进行开发，您的大部分集成测试将是验收测试。这些是关于用户所看到的，因此他们从外部与系统交互。他们不查看数据库或以其他方式进入幕后。他们不需要：如果有理由将某些内容保存在数据库中，如果它出现在屏幕上，我们就会知道它是否有效。他们确实需要测试是否已发送电子邮件或是否在第三方信用卡处理系统中创建了一个帐户，因为这些是用户看到的一部分。
在您实施了所有验收测试后，您可能会将系统视为一名工程师，并决定系统中的类如何与其他类或与外部系统交互的某些方面没有经过充分测试。首先，确定这些是否告诉您真正应该在验收测试中出现的需求（通常是这种情况），如果是，请改进验收测试。
您可能仍然觉得需要编写更多不是验收测试的集成测试，它们可能需要直接查看数据库或其他内容。根据我的经验，这些是少数。
也就是说，有时验收测试在场景中间停止并仅测试副作用是有实际意义的，因为另一个验收测试已经描述了场景的其余部分。 （例如，可能有 18 种不同的方法可以在您的应用程序中创建帐户。也许它们都会在中期场景中导致数据库中的相同帐户。）同样，您可能想要伪造一些数据库状态并在中期开始- 避免重复的场景；通常通过用户登录来执行此操作。
在您的应用程序实现所有验收测试并具有良好的集成覆盖率后，使用单元测试测试细节，这会测试副作用。但是，如果您的验收/集成测试已经充分测试了一段给定的代码，那么它就不需要单元测试，而且它的副作用可能永远不会被直接测试——这很好。
【讨论】：