集成测试应包含多少？哪些副作用经过测试？

Question

假设我有一项功能要求，即当用户成功注册付费帐户时，会发生以下几种情况：

1. 创建了用户的帐户
2. 用户的信用卡结算，产生新的交易记录
3. 收据通过电子邮件发送给用户

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

集成测试应该涵盖多少？

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

• 是否创建了帐户记录？
• 创建了一个交易？
• 交易的金额是否正确？
• 收据邮件已发送？

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

Answer 1

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

在您实施了所有验收测试之后，您可能会将系统视为工程师，并决定系统中的类如何相互交互或与外部系统交互的某些方面未得到充分测试。首先，确定这些是否告诉您应该在验收测试中确实存在的要求（通常是这种情况），如果是，则改进验收测试。

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

尽管如此，有时它会使验收测试在中间场景中停止并且仅测试副作用，这是有用的，因为另一个验收测试已经描述了场景的其余部分。 （例如，在您的应用程序中创建一个帐户可能有18种不同的方式。也许它们在中间场景中都会在数据库中生成相同的帐户。）同样，您可能想要伪造一些数据库状态并从中间开始 - 避免重复的场景;用户登录通常会这样做。

在您的应用程序实现所有验收测试并具有良好的集成覆盖率后，请使用单元测试来测试详细信息，测试副作用。但是，如果您的验收/集成测试已经充分测试了一段代码，那么它不需要进行单元测试，其副作用可能永远不会直接测试 - 这很好。