假设我有一个功能需求，当用户成功注册付费帐户时，会发生以下几件事:
- 创建用户账号
- 用户信用卡被计费，产生一个新的交易记录
- 收据通过电子邮件发送给用户
我见过的大多数rspec集成或黄瓜测试都非常专注于屏幕上显示的内容，例如expect(page).to have_text(X)或Then I should see X
这里的集成测试应该涵盖多少内容?
集成测试是否检查…
- 帐户记录已创建?
- 事务已创建?
- 交易金额是否正确?
- 收据邮件已发送?
为什么或为什么不?如果没有，在哪里/如何测试这些类型的副作用?
如果您在外部进行开发，那么您的大多数集成测试将是验收测试。这些是关于用户所看到的，所以他们从外部与系统进行交互。他们不会查看数据库，也不会深入到幕后。他们不需要这样做:如果有理由在数据库中保存某些内容，如果它出现在屏幕上，我们就会知道它是否有效。他们确实需要测试是否发送了电子邮件或是否在第三方信用卡处理系统中创建了帐户，因为这些都是用户看到的内容的一部分。
在您实现了所有的验收测试之后，您可能会以工程师的身份来看待系统，并确定系统中的类如何相互作用或与外部系统进行交互的某些方面没有得到充分的测试。首先，决定这些是否告诉了您应该在验收测试中出现的需求(通常是这种情况)，如果是，则改进验收测试。
您可能仍然觉得需要编写更多的集成测试，而不是验收测试，并且它们可能需要直接查看数据库或其他东西。根据我的经验，这些人是少数。
也就是说，有时候验收测试在场景中间停止并且只测试副作用是有实际意义的，因为另一个验收测试已经描述了场景的其余部分。(例如，也许有18种不同的方法可以在你的应用程序中创建一个帐户。也许它们都会在中间场景的数据库中产生相同的帐户。)类似地，您可能希望伪造一些数据库状态并在场景中期启动，以避免重复;这在用户登录时很常见。
在您的应用程序实现了所有的验收测试并具有良好的集成覆盖率之后，使用单元测试来测试细节，单元测试可以测试副作用。但是，如果您的验收/集成测试已经充分测试了给定的代码片段，那么它就不需要单元测试，并且它的副作用可能永远不会被直接测试——这很好。