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