JUnit 5 –扩展模型

最新推荐文章于 2021-01-09 11:48:20 发布

dnc8371

最新推荐文章于 2021-01-09 11:48:20 发布

阅读量135

点赞数

文章标签： python java 设计模式 spring 大数据

我们已经对Java最普遍的测试框架的下一个版本了解很多。现在让我们看一下JUnit 5扩展模型，该模型将允许库和框架将自己的实现添加到JUnit中。

总览

设定
基本
建筑
扩展模型
条件
注射
…

在新兴的《 JUnit 5用户指南》中可以找到您将在此处阅读的更多内容以及更多内容。请注意，它基于Alpha版本，因此可能会发生变化。

确实，我们鼓励我们提出问题或提出请求，以便JUnit 5可以进一步改进。请利用这个机会！这是我们帮助JUnit帮助我们的机会，因此，如果您能在这里看到一些改善，请确保将其上游。

如有必要，此帖子将得到更新。我在这里显示的代码示例可以在GitHub上找到。

JUnit 4扩展模型

首先让我们看一下JUnit 4是如何解决该问题的。它具有两个部分竞争的扩展机制：运行程序和规则。

跑步者

测试运行者管理测试的生命周期：实例化，调用设置和拆卸方法，运行测试，处理异常，发送通知等。而JUnit 4提供了实现所有这些功能的实现。

在4.0中，只有一种扩展JUnit的方法：创建一个新的运行器并使用@RunWith（MyRunner.class）注释测试类，以便JUnit使用它而不是其自己的实现。

该机制非常繁重，并且不方便扩展。而且它有一个非常严格的限制：每个测试班级只能有一位跑步者，这使得他们无法组成。因此，无法同时利用Mockito和Spring跑步者的功能。

规则

为了克服这些限制，JUnit 4.7引入了rules ，它们是测试类的带注释字段。 JUnit 4将测试方法（和其他操作）包装到一条语句中，并将其传递给规则。然后，他们可以在执行语句之前和之后执行一些代码。此外，测试方法通常在执行期间在规则实例上调用方法。

一个示例是临时文件夹规则：

public static class HasTempFolder {
	@Rule
	public TemporaryFolder folder= new TemporaryFolder();
 
	@Test
	public void testUsingTempFolder() throws IOException {
		File createdFile= folder.newFile("myfile.txt");
		File createdFolder= folder.newFolder("subfolder");
		// ...
	}
}

由于使用@Rule批注，JUnit调用带有包装方法testUsingTempFolder的语句的文件夹。编写此特定规则是为了使文件夹创建一个临时文件夹，执行测试，然后再删除该文件夹。然后，测试本身可以在临时文件夹中创建文件和文件夹。

其他规则可能会在Swing的事件分发线程中运行测试，建立和删除数据库，或者如果测试运行时间过长，则让测试超时。

规则是一个很大的改进，但通常仅限于在测试运行之前和之后执行一些代码。他们无法帮助无法在该框架内实现的扩展。

事态

JUnit有两种相互竞争的扩展机制，每种都有其自身的局限性。

因此，自JUnit 4.7起就有两种竞争的扩展机制，每种机制都有其自身的局限性，但也有很多重叠之处。这使得干净扩展很困难。此外，编写不同的扩展可能会出现问题，并且通常无法实现开发人员希望的那样。

由Tony Walmsley在CC-BY 2.0下发布

JUnit 5扩展模型

JUnit Lambda项目具有几个核心原则，其中之一是“优先于功能而不是扩展点”。从字面上看，这转化为新版本的整体机制–这不仅是扩展JUnit 5的唯一机制，也是最重要的机制。

延伸点

JUnit 5扩展可以声明对测试生命周期的某些特定时刻感兴趣。当JUnit 5引擎处理测试时，它将逐步通过这些步骤并调用每个已注册的扩展。从外观上看，这些是扩展点：

测试实例后处理
之前回调
有条件的测试执行
每次回调之前
参数解析
异常处理
AfterEach回调
毕竟回调

（不必担心它们是否每个都还不清楚。我们稍后将介绍其中的一些。）

每个扩展点对应一个接口。他们的方法采用的参数可以捕获测试生命周期中特定点的上下文，例如测试实例和方法，测试名称，参数，注释等。

扩展可以实现任意数量的那些接口，并且将由引擎使用相应的参数进行调用。然后，它可以执行实现其功能所需的任何操作。要考虑的一个细节：引擎在实例化扩展时以及实例保持存在的时间方面不做任何保证，因此它们必须是无状态的。他们需要维护的任何状态都必须写入JUnit并从中加载。

创建扩展后，剩下要做的就是告诉JUnit。这是那么容易，因为添加@ExtendWith（MyExtension。类），需要延长测试类或方法。

实际上，存在一个稍微不那么冗长和更多显示的选项。但是为此，我们首先必须看看JUnit扩展模型的另一个Struts。

自定义注释

JUnit 5 API由注释驱动，并且引擎在检查它们是否存在时会做一些额外的工作：它不仅在类，方法和参数上查找注释，还在其他注释上查找。并且它将发现的所有内容都视为立即存在于检查的元素上。注释可以通过所谓的meta-annotations进行注释，很酷的是，所有JUnit注释都是完全meta的。

这样就可以轻松地创建和编写在JUnit 5中完全可用的注释：

/**
 * We define a custom annotation that:
 * - stands in for '@Test' so that the method gets executed
 * - has the tag "integration" so we can filter by that,
 *   e.g. when running tests from the command line
 */
@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Test
@Tag("integration")
public @interface IntegrationTest { }

然后我们可以像这样使用它：

@IntegrationTest
void runsWithCustomAnnotation() {
    // this gets executed
    // even though `@IntegrationTest` is not defined by JUnit
}

或者我们可以为扩展创建更简洁的注释：

@Target({ ElementType.TYPE, ElementType.METHOD, ElementType.ANNOTATION_TYPE })
@Retention(RetentionPolicy.RUNTIME)
@ExtendWith(ExternalDatabaseExtension.class)
public @interface Database { }

现在我们可以使用@Database代替@ExtendWith（ExternalDatabaseExtension。类）。并且由于我们添加了ElementType 。 ANNOTATION_TYPE到允许的目标列表中，它也是一个元注释，我们或其他人可以对其进行进一步的组合。

假设我们要对某些测试的运行时间进行基准测试。首先，我们创建要使用的注释：

@Target({ ElementType.TYPE, ElementType.METHOD, ElementType.ANNOTATION_TYPE })
@Retention(RetentionPolicy.RUNTIME)
@ExtendWith(BenchmarkCondition.class)
public @interface Benchmark { }

它已经指向BenchmarkCondition ，我们将在接下来实现。这是我们的计划：

衡量整个测试类的运行时间，存储执行任何测试之前的时间
衡量各个测试方法的运行时间，存储每次测试之前的时间
执行测试方法后，检索测试的启动时间，计算并打印结果运行时
执行完所有测试后，检索类的启动时间，计算并打印结果运行时
仅当用@Benchmark注释类或方法时，才执行任何此操作

最后一点可能不是立即显而易见的。为什么扩展未处理未使用@Benchmark注释的方法？这源于以下事实：如果将扩展应用于类，它将自动应用于其中的所有方法。因此，如果我们的要求表明我们可能希望对类进行基准测试，但不一定要对所有单个方法进行基准测试，则需要排除它们。我们通过检查它们是否被单独注释来做到这一点。

碰巧的是，前四个点直接对应于生命周期回调BeforeAll ， BeforeEach ， AfterEach ， AfterAll ，因此我们要做的就是实现四个对应的接口。这些实现非常简单，它们只是按照我们上面所说的去做：

public class BenchmarkCondition implements
		BeforeAllExtensionPoint, BeforeEachExtensionPoint,
		AfterEachExtensionPoint, AfterAllExtensionPoint {

	private static final Namespace NAMESPACE =
			Namespace.of("BenchmarkCondition");

	@Override
	public void beforeAll(ContainerExtensionContext context) {
		if (!shouldBeBenchmarked(context))
			return;

		writeCurrentTime(context, LaunchTimeKey.CLASS);
	}

	@Override
	public void beforeEach(TestExtensionContext context) {
		if (!shouldBeBenchmarked(context))
			return;

		writeCurrentTime(context, LaunchTimeKey.TEST);
	}

	@Override
	public void afterEach(TestExtensionContext context) {
		if (!shouldBeBenchmarked(context))
			return;

		long launchTime = loadLaunchTime(context, LaunchTimeKey.TEST);
		long runtime = currentTimeMillis() - launchTime;
		print("Test", context.getDisplayName(), runtime);
	}

	@Override
	public void afterAll(ContainerExtensionContext context) {
		if (!shouldBeBenchmarked(context))
			return;

		long launchTime = loadLaunchTime(context, LaunchTimeKey.CLASS);
		long runtime = currentTimeMillis() - launchTime;
		print("Test container", context.getDisplayName(), runtime);
	}

	private static boolean shouldBeBenchmarked(ExtensionContext context) {
		return context.getElement().isAnnotationPresent(Benchmark.class);
	}

	private static void writeCurrentTime(
			ExtensionContext context, LaunchTimeKey key) {
		context.getStore(NAMESPACE).put(key, currentTimeMillis());
	}

	private static long loadLaunchTime(
			ExtensionContext context, LaunchTimeKey key) {
		return (Long) context.getStore(NAMESPACE).remove(key);
	}

	private static void print(
			String unit, String displayName, long runtime) {
		System.out.printf("%s '%s' took %d ms.%n", unit, displayName, runtime);
	}

	private enum LaunchTimeKey {
		CLASS, TEST
	}
}

有趣的细节是shouldBeBenchmarked ，它使用JUnit的API毫不费力地确定当前元素是否被@Benchmark （元）注释，以及writeCurrentTime / loadLaunchTime ，后者使用存储来写入和读取启动时间。

您可以在GitHub上找到代码。

接下来的文章将讨论条件测试执行和参数注入，并显示如何使用相应扩展点的示例。如果您迫不及待，请查看这篇文章，其中展示了如何将两个JUnit 4规则（条件禁用和临时文件夹）移植到JUnit 5。

摘要

我们已经看到，JUnit 4的运行者和规则对于创建干净，强大且可组合的扩展并不是理想的选择。 JUnit 5旨在通过更通用的扩展点概念来克服它们的局限性。它们允许扩展程序指定要在测试生命周期中的哪些时间点进行干预。我们还研究了元注释如何使自定义注释的创建变得容易。

你怎么看？

翻译自: https://www.javacodegeeks.com/2016/04/junit-5-extension-model.html

dnc8371

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
JUnit 5 –扩展模型

我们已经对Java最普遍的测试框架的下一个版本了解很多。现在让我们看一下JUnit 5扩展模型，该模型将允许库和框架将自己的实现添加到JUnit中。总览设定基本建筑扩展模型条件注射 … 在新兴的《 JUnit 5用户指南》中可以找到您将在此处阅读的更多内容以及更多内容。请注意，它基于Alpha版本，因此可能会发生变化。确实，我们鼓励...
复制链接

扫一扫