单元测试，系统测试，红色测试，绿色测试

我们倾向于根据它们涵盖的内容对不同类型的测试进行分类。 单元测试覆盖了代码的一小部分，通常是一个方法或一个类，而我们模拟了其余的交互。 集成测试涵盖了多个组件，然后模拟其他边界。 系统测试及其兄弟，端到端测试涵盖了越来越多的领域。

这些类别在语义上是正确的，并且在“我们应该拥有多少”的上下文中是相关的。 就像在测试金字塔中一样：

测试金字塔告诉我们，与集成测试相比，我们应该有更多的单元测试，而与端到端测试相比，我们应该有更多的集成测试。 有以下几个原因：

• 我们可以用较小的测试覆盖更多的代码。 从数学上讲，覆盖代码的一小部分是线性顺序的，而更长的工作流（覆盖了组件之间交互的不同选项）则变成了指数顺序。
• 单元测试更容易编写，因为它们需要较少的设置。 系统测试需要较大的设置，难以编写。 虽然我们可以同时编写两者，但有可能是我们编写的单元测试要多于系统测试。
• 单元测试不如大型测试脆弱。 系统和集成测试通常取决于环境和可用资源，并且如果它们由于某种原因而消失，则测试将失败，尽管这并不是他们实际测试的内容。 一世
• 代码中有很多路径不能被大型测试覆盖，而可以被单元测试覆盖。 您可能会问为什么会这样（我通常会这样做），通常答案是YAGNI。 但是因为有代码，所以最好对其进行测试，而单元测试在此方面做得更好。
• 使用“测试优先”功能时，TDD的反馈周期比ATDD的短得多。 TDD可以进行更多的测试，而这些测试是在单元级别进行的。

因此，您可能会问–如果单元测试做得如此出色，为什么我需要其他测试？

答案，我的朋友，在于颠倒的测试信任金字塔：

因为单元测试不能测试整个系统，并且测试的系统流程证明了系统可以正常工作，所以我们倾向于更加信任它们。 流程时间越长，信任就越多，我们对测试的信心就会增强。

哦。 因此，端到端测试必须是批次中最好的。 为什么不写更多的东西呢？

我们可以重新访问以前的列表，但是我想谈谈价值。

考试的价值是什么？

自动化测试（以及一般测试）会给我们反馈。 那是他们的主要价值，但不是唯一的价值。

您会看到，如果每个测试都通过了，那么端到端测试的价值将是最大的。 与涵盖相同代码的单元测试相比，它使我们对系统的运行更有信心。

但是，如果失败，那就改变了。

当我们的系统测试失败时，我们什至不知道该寻找什么：问题是否起作用？ 环境？ 在流程的哪一点出现了问题？ 但是，当单元测试涵盖了相同的失败系统测试所要通过的一些代码时，我们对问题有了更加集中，孤立的描述，这更容易解决。

那么我们应该写什么样的测试呢？

回到测试金字塔，比系统测试更多的单元测试。 我们希望绿色系统测试能给我们带来信心，但我们希望通过较小的兄弟姐妹解决问题。

切记：绿色系统测试使我们更有信心。 但是红色单元测试的价值要大于红色系统测试的价值。

翻译自: https://www.javacodegeeks.com/2015/02/unit-test-system-test-red-test-green-test.html