集成测试的最佳实践

Question

我在看着stackoverflow和可能罚款one或two有一个类似的标题比这个问题，但没有回答我问。对不起，如果这是重复的。

在统一测试中，有一个指导说“One assertion per test”。通过阅读stackoverflow和互联网，人们普遍认为这个规则可以放松一点，但是每个单元测试都应该测试代码的一个方面，或者一个行为。这很有效，因为当测试失败时，您可以立即看到失败并修复它，很有可能测试在未来的其他时间点不会再次失败。

这适用于Rails单元测试，我一直在使用它进行功能测试，没有任何问题。但是，当涉及到集成测试时，在您的测试中应该有许多断言是有点含蓄的。除此之外，他们通常重复在功能和单元测试中已经完成过的测试。集成测试的

1. 长度：

   因此，在这两个因素编写集成测试时，什么都考虑好做法，如何来衡量，当集成测试应在两个来splited？请求数量？或更大一些总是更好

2. 集成测试的断言数：它是否应该重复单元测试和功能测试中提出的有关系统当前状态的断言，或者每次应该只有5个断言结束以测试是否生成了正确的输出？

Answer 1

希望有人会提供一个更权威的答案，但我的理解是，一个集成测试应该建立在一个特定的功能周围。例如，在网上商店中，您可以编写一个集成测试以确保可以将商品添加到购物车，并进行另一个集成测试以确保可以签出。

集成测试需要多长时间？

只要覆盖一个特征，不再需要。有些功能很小，有些功能很大，而且它们的大小与品味有关。当它们太大时，它们可以很容易地分解成几个逻辑子特征。当它们太小时，它们的集成测试看起来像是视图或控制器测试。

它们应该有多少断言？

虽然尽可能少，但仍然有用。所有测试都是如此，但是它对集成测试来说是双倍的，因为它们太慢了。这意味着只测试最重要的东西，并且不要测试其他数据隐含的东西。在结帐功能的情况下，我可能会断言该订单是为合适的人创建的，并且总计正确，但是保留未测试的确切项目（因为我的体系结构可能会从项目中生成总计）。在此之前我不会做任何断言，因为遍历应用程序 - 填充此字段，单击该按钮，等待此模式打开 - 涵盖我需要测试的所有集成行为，以及其他任何可能由视图测试覆盖是否需要进行测试。一般而言，这意味着单元测试往往只需要几行代码，并且前面有一个更大的设置块，但Rails集成测试往往需要十几行或更多（其中大部分是交互操作） ，并且完全没有设置块。

Answer 2

积分测试的长度：我同意这里的长度并不重要。这更多的是关于你正在测试的功能以及测试它需要多少步骤。例如，假设您正在测试创建项目的五个步骤的向导。如果相关数据出现在屏幕上，我会在一个测试结束时检查所有五个步骤。不过，如果向导允许需要覆盖不同的场景，我会拆分测试。断言在集成测试

编号：不要测试在其它测试已经测试过的东西，但确保用户期望得到满足。因此，测试一下，用户期望在屏幕上看到的不是后端特定的代码。有时候您可能仍然需要检查数据库中是否有正确的数据，例如，当数据不应该出现在屏幕上时。