junit4 集成测试_使用JUnit规则进行干净的集成测试

junit4 集成测试

JUnit Rules的优势，尤其是在进行集成测试时，几乎不能被高估。 在本文中，我们将阐明ExternalResource扩展的有用性。 在我们必须使用抽象外部资源的第三方库的情况下，这简化了灯具控制。 作为示例，我们将看看如何基于Git提交日志消息来验证对条目列表的正确检索。

什么是集成测试？

“关注点分离”可能是软件设计和实现中最重要的单个概念。
语用单元测试[HUTH03]

通常，我们使用单元测试来检查一小段生产代码是否按预期工作。 但是重要的是要了解，这类测试仅限于开发人员负责的代码。 为了澄清这一点，请考虑合并第三方库来管理对文件，数据库，Web服务等的访问。

测试将隐式调用第三方组件的代码，因为我们的被测系统 （SUT）依赖于这些组件（DOC）[MESZ07]。 如果外部资源之一不可用，尽管开发人员的代码可能没有问题，但它们将失败。 此外，访问这些资源通常很慢，并且设置测试装置通常很麻烦。 更不用说脆弱性了，它是由不同库版本的潜在语义变化引起的。

所有这些缺点建议通过适配器抽象[FRPR10]将应用程序的代码与第三方代码分开。 不仅仅是抽象适配器组件可以在应用程序的问题域方面提供表达性的API，它还允许使用轻量级的替代测试double （通常表示为嘲笑）来替换基于第三方代码的实现。

使用JUnit进行测试

使用JUnit进行测试是Java开发人员可以学习的最有价值的技能之一。 无论您的背景是什么，无论您是只是想建立一个安全网以减少桌面应用程序的性能下降，还是要基于健壮且可重复使用的组件来提高服务器端的可靠性，都需要进行单元测试。

弗兰克（Frank）写了一本书，它为使用JUnit进行测试的基本知识提供了深刻的切入点，并为您准备与测试相关的日常工作挑战做好了准备。

学到更多…

这消除了先前列出的有关单元测试的依赖性问题。 双重测试的设置成本低廉，可以将测试中的系统与第三方代码隔离开，并保持测试快速可靠[MESZ07]。 但是，它剩下的工作是测试适配器组件的正确行为。 这是集成测试开始起作用的时候。

该术语指的是软件测试中的阶段，在该阶段中，将各个软件模块组合在一起并作为一个组进行测试[INTTES]。 可以说，我们使用适配器抽象将一个或多个第三方模块组合在一起以提供某种功能。 由于从应用程序的角度来看，此类适配器是低级组件，因此该策略隐式导致了一种自下而上的方法，该方法首先测试最低级别的组件，然后再用于促进更高级别组件的测试。

您可能想知道为测试目的调整设计是否不是一件坏事。 但是，通过使用适配器，您可以确定应用程序和第三方代码之间的界限。 如果新的库版本引入了稍微不同的行为，则只需调整适配器代码即可再次通过相应的集成测试。 您的实际应用程序代码（包括单元测试）将不受影响！ 此外，您可以通过提供适当的适配器轻松切换到其他供应商。 因此，遵循这种做法还可以带来更健康的应用程序设计。 [APPE15]

外部资源处理

不幸的是，在编写集成测试时，我们必须面对通过使用测试倍数来避免单元测试所遇到的问题。 特别是从编码角度来看，安装测试夹具通常需要大量的精力。 最重要的是，我们还必须做好适当的内务处理[MESZ07]。 例如，这意味着我们可能需要在测试执行后重置外部资源的状态。 后者对于确保后续测试独立运行很重要。 这样一来，测试所做的资源修改就不会伪造其后继者的验证结果。

为了减少设置和拆卸代码的经常性开销，将普通段落交换到测试帮助程序类中似乎很自然。 考虑一下系统环境变量，主数据