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