我查看了stackoverflow，可以解决一两个与这个标题相似的问题，但没有一个能回答我的问题。对不起，如果这是重复的。
在统一测试中，有一条指南说“每个测试一个断言”。通过阅读 stackoverflow 和互联网，人们普遍认为这个规则可以放宽一点，但是每个单元测试都应该测试代码的一个方面，或者一个行为。这很有效，因为当测试失败时，您可以立即看到失败的原因并修复它，该测试很可能在未来的其他时间不会再次失败。
这适用于 Rails 单元测试，我也一直在使用它进行功能测试，没有任何问题。但是当涉及到集成测试时，在测试中应该有很多断言有点隐含。除此之外，他们通常会重复在功能测试和单元测试中已经完成一次的测试。
那么，在这两个因素中编写集成测试时，哪些被认为是好的做法：
希望有人会提供更权威的答案，但我的理解是集成测试应该围绕特定功能构建。例如，在在线商店中，您可能会编写一个集成测试以确保可以将商品添加到您的购物车，并编写另一个集成测试以确保可以结帐。
集成测试应该多长时间？
只要覆盖一个功能，就没有更多了。有些功能很小，有些很大，它们的大小是一个品味问题。当它们太大时，它们可以很容易地分解成几个逻辑子特征。当它们太小时，它们的集成测试看起来像视图或控制器测试。
他们应该有多少断言？
尽可能少，同时仍然有用。对于所有测试都是如此，但对于集成测试来说则是双倍的，因为它们太慢了。这意味着只测试最重要的东西，而尽量不测试其他数据暗示的东西。在结帐功能的情况下，我可能会断言订单是为正确的人创建的并且具有正确的总数，但未测试确切的项目（因为我的架构可能会从项目生成总数）。在此之前我不会做出任何我不必做的断言，因为遍历应用程序——填写这个字段，点击那个按钮，等待这个模式打开——涵盖了我需要测试的所有集成行为，其他任何事情都可以如果它们需要被测试，则被视图测试覆盖。
总的来说，这意味着单元测试往往只有几行长并且前面有一个更大的设置块，Rails 集成测试往往有十几行或更多（其中大部分是交互），并且缺乏完全设置块。
集成测试的长度：我同意这里的长度并不重要。它更多的是关于您正在测试的功能以及测试它需要多少步骤。例如，假设您正在测试一个创建项目的五个步骤的向导。如果相关数据出现在屏幕上，我会将所有五个步骤放在一个测试结束检查中。但是，如果向导允许需要涵盖的不同场景，我会拆分测试。
集成测试的断言数量：不要测试已经在其他测试中测试过的东西，但要确保满足用户的期望。所以测试一下，用户希望在屏幕上看到的不是后端特定的代码。有时您可能仍需要检查数据库中的正确数据，例如当它不应该出现在屏幕上时。