关于高效企业测试的思考（1/6）

企业中的测试仍然不是应有的广泛使用的话题。编写尤其是维护测试需要花费时间和精力，但是缩短软件测试并不是解决方案。为了提高测试效率，应该追求哪些范围，方法和测试技术？

我根据许多实际项目，结合了我在企业测试中的经验和意见，提出了一系列建议。特别是对于比“ hello world”要复杂得多的应用程序，遵循哪种方法至关重要。我将主要关注测试应用程序的功能行为，即它们如何很好地实现我们的业务逻辑。在下面的内容中，我将解释有关如何在不同的范围和使用不同的方法来提高测试效率的最佳实践：

想法与约束
单元测试
用例测试
代码级集成测试
系统测试
开发工作流程和管道
测试代码质量和可维护的测试
测试框架和技术

介绍

不管测试的类型和范围如何，拥有测试套件的目的都是为了验证我们的应用程序可以在生产中按预期工作。从用户的角度来看，这应该是验证系统是否完成其工作的主要动机。

由于人的注意力跨度和上下文切换是一回事，因此我们需要确保我们的测试能够快速运行和验证，并具有可预测的结果。在编写代码时，快速验证（少于或等于一秒钟）对于确保高效的工作流程以及确保我们不会分散注意力至关重要。

另一方面，我们需要确保测试保持可维护性。软件更改非常频繁，并且具有足够的功能测试覆盖范围，生产代码中的每个功能更改都需要更改测试范围。理想情况下，测试代码仅在功能（即业务逻辑）发生变化时才发生变化，而不是在代码清理和重构时发生变化。通常，测试方案需要使非功能性的结构更改成为可能。

当我们研究不同的测试范围时（我们将更详细地介绍），就会出现一个问题，即哪个范围需要花费更多的时间和精力。对于微服务应用程序或我们拥有大量分布和集成的任何系统，验证系统边界的集成测试变得更加重要。因此，我们需要一种有效的方法来验证本地开发过程中的整个应用程序，同时保持应用程序环境和设置与生产环境尽可能相似。

原则与约束

无论选择哪种解决方案，我们都为测试套件定义以下原则和约束：

测试需要快速执行和验证，并提供快速反馈。对于没有任何进一步集成的单元测试，我们应该能够在一秒钟内运行数百个测试。对于集成测试，执行时间取决于场景，理想情况下不超过一秒。
在开发过程中，测试还必须在集成级别上提供快速反馈。这要求测试上下文快速启动，或者在我们编写代码时保持运行。因此，应该有可能通过少于5秒的重新部署和测试周转时间来建立有效的开发周期。
测试需要使其能够重构生产代码，而无需在测试范围内进行重大更改。不会更改应用程序功能行为的代码更改应仅导致最小的测试代码更改。
确实会更改功能行为的代码更改应同样会导致有限的测试代码更改。例如：“将HTTP边界交换到gRPC，将JSON交换到其他东西，甚至交换企业框架等，要花多少精力？”。
测试技术和方法必须与根据我们的业务需求量身定制适当的抽象，委托和代码质量兼容。我们需要能够设计表达性API，扩展潜在的DSL以及设计正确的抽象。
测试技术需要支持一种“开发模式”，即以一种能够在集成环境中进行即时更改和重新部署的方式运行该应用程序，例如服务器的“开发”和调试模式， Quarkus的开发模式，网真，监视部署方法等。
测试方法必须与单独设置开发和测试生命周期兼容。也就是说，开发人员必须能够在测试生命周期之外设置和配置其本地环境（例如，使用Shell脚本），然后在已经设置好的环境中快速运行测试方案。出于灵活性和可重用性的原因，各个测试用例不应管理测试设置的生命周期。
我们需要能够在多个范围内重用测试场景，例如，一次定义业务场景，并将设置重新用于系统测试，负载测试，在本地或针对外部部署的环境中运行。复制方案应该很简单，方案应该只包含几行代码，通过使用不同的实现来达到不同的目的。

在本系列的下一部分中，我们将研究代码级单元测试和组件或用例测试，以及它们如何与这些原理和约束相匹配。