集成测试最佳实践

Question

我在堆栈溢出中查看，可以细写一或二的问题，这些问题的标题与这个相似，但没有一个回答我的问题。如果这是复制的，很抱歉。

在统一测试中，有一个指南是"每个测试一个断言“。通过阅读堆栈溢出和internet，人们普遍认为这个规则可以放松一点，但是每个单元测试都应该测试代码的一个方面，或者一个行为。这很好，因为当测试失败时，您可以立即看到哪些失败并修复它，很可能以后测试不会再次失败。

这对于Rails单元测试很好，而且我也一直在使用它进行功能测试，没有任何问题。但是，当涉及到集成测试时，您应该在测试中有许多断言，这在某种程度上是隐含的。除此之外，他们通常会重复已经在功能测试和单元测试中完成过的测试。

因此，在编写这两个因素的集成测试时，哪些是良好的实践：

1. 集成测试的长度：如何度量集成测试何时被分割成两部分？请求数量？或者更大的总是更好
2. 关于集成测试的断言数量：是每次重复单元测试和功能测试中关于系统当前状态的断言，还是应该在结束时只有5个左右的断言来测试是否生成了正确的输出？

Answer 1

希望有人能提供一个更权威的答案，但我的理解是，集成测试应该围绕特定的特性构建。例如，在在线商店中，您可以编写一个集成测试，以确保可以向购物车中添加项目，还可以编写另一个集成测试，以确保可以签出。

集成测试应该持续多长时间？

只要它能覆盖一个功能，就不会有更多。有些特征是小的，有些是大的，它们的大小取决于口味。当它们太大时，它们很容易被分解成几个逻辑子特征。当它们太小时，它们的集成测试看起来就像视图或控制器测试。

他们应该有多少断言？

尽可能少，但仍然有用。对于所有的测试来说都是这样，但是集成测试会加倍，因为它们太慢了。这意味着只测试最重要的东西，并且尽量不测试其他数据所隐含的东西。在签出功能的情况下，我可能会断言，订单是为正确的人创建的，并且拥有正确的总计，但没有对确切的项进行测试(因为我的体系结构可能会从项生成总计)。在此之前，我不需要做任何断言，因为遍历应用程序--填充此字段、单击该按钮、等待此模式打开--涵盖了我需要测试的所有集成行为，如果需要进行测试，其他任何东西都可以被视图测试覆盖。

总的来说，这意味着单元测试往往只有几行长，前面有一个更大的安装块，而Rails集成测试往往有十几行长或更长(大部分是交互)，并且完全缺少一个安装块。

Answer 2

集成测试的长度：--我同意这里的长度并不那么重要。它更多的是关于您正在测试的特性，以及测试它需要采取多少步骤。例如，假设您正在测试一个由五个步骤组成的向导，该向导创建一个项目。我会把所有的五个步骤放在一个测试结束，检查相关数据是否出现在屏幕上。但是，如果向导允许需要涵盖的不同场景，我将拆分测试。

关于集成测试的断言数量：不测试已经在其他测试中测试过的东西，但是确保用户的期望得到满足。那么测试什么，用户希望在屏幕上看到的不是后端的特定代码。有时，您可能仍然需要检查数据库中的正确数据，例如，当数据不应该出现在屏幕上时。